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ABSTRACT 


Navy leadership has articulated interest in understanding game changing 
technologies that permit employment of network centric (versus platform centric) battle 
management. To explore this problem statement, the project team employed a model 
based systems engineering approach to examine segments of both the operational and 
physical networking and communication architectures. Various alternatives were 
explored with the intent in making recommendations for technology investment by the 
U.S. Navy. Research conducted by the project team on industry analogues shows that 
financial industry also relies on network technology as well as operational architecture to 
effectively execute transactions valued at trillions of dollars daily on a global scale. 
Global banking systems employ a “Clearing House” approach that settles critical 
transactions quickly and “keeps track” of all transactions. This allows Banks to quickly 
understand debits and credits and minimize liquidity risk. Re-thinking conventional data 
management into a structure that address “mission risk” as key metric may allow 
alternative architectures to be employed for fleet battle management. The project team’s 
research and modeling showed that while communications and network technologies may 
offer improvement, game changing approaches would more likely emerge as a result 
from rethinking organizational communication architectures. 
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EXECUTIVE SUMMARY 


Modem warfare is predieated on the availability of reliable information and data 
flows. Insofar as weapon systems must be effeetive, so too must the networks that 
undergird them. However, while a fighter jet’s range, a missile’s aeeuraey, or a ship’s 
speed are relatively easy to quantify, great difficultly lies in delineating measures of 
effectiveness (MOE) for supporting commanders’ decision-making, both in planning and 
in execution. To that end. Navy leadership has expended much effort in helping integrate 
the relevant organizations for command and control (C2) into a more cohesive stmcture. 
In particular, the realignment of the Navy’s intelligence (N2) and command, control, 
communications, and computers (N6) directorates were, in the words of Admiral Gary 
Roughead, “.. .the right way, this is where we have to go, and it will make us much, much 
more effective.’’(Roughead 2009) What remains to be seen, however, is how we will get 
to this desired end-state of a network being fully supportive of a commander’s decision 
cycle. 

The members of Cohort 311-092W from the Space and Naval Warfare Systems 
Command were tasked to develop and define Measures of Performance (MOP), MOE 
and Quality of Service (QoS) characteristics required by Naval networks to support Elect 
Battle Management. Eindings will be used to support one of the fifteen Information 
Dominance Roadmaps directed by Deputy Chief of Naval Operations for Information 
Superiority. In particular the DCNO objectives are to: 

“Pioneer, field and employ game-changing capabilities to ensure 
Information Dominance over adversaries and Decision Superiority for 
commanders, operational forces and the nation.’’(Department of the Navy, 

Deputy Chief ofNaval Operations for Information Dominance 2010) 

The project team employed a model-based systems engineering approach to 
document the requirements, define the operational architecture, define high level 
functions that the networks must support, and model different system of system 
alternatives. Naval Warfare Publications, Navy Tactics, Technique and Procedure 
Publications and leadership writing were analyzed to refine a set of coincide technical 
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performance measure that naval networks need to satisfy to support Fleet Battle 
Management. These key measures are; 

a. Delay time for propagation of vital situational awareness information 
throughout the network 

b. Percentage of time soft-real-time requirements that can be maintained 
throughout the network 

c. Percentage of time hard-real-time requirements that can be maintained 
throughout the network 

Fleet stakeholders were engaged throughout the process to develop a value system based 
on these concise measures that was used to analyze these alternatives. 

The project team researched how other industries might address the issue of 
meeting the key measures. It was discovered that the Global banking System employs 
architectures and technology in order to address many of the same requirements. A 
concept of a transaction Clearing House was identified as an alternative way to build 
trusted transactions between operational nodes enhancing Command and control and 
improving fleet battle management 

The project developed a representation of the operational functional architecture 
using the Vitech CORE system engineering toolset. A huge advantage to this approach is 
the ability to model the effect of operational activities and organization with respect to 
meeting the key measures. A significant finding was that the organizational construct 
had significant impact on how well Fleet Battle Management can be supported. 

The Joint Communication Simulation System (JCSS) toolset was utilized to 
develop a physically representative model to understand how different networking 
architectures could be employed. Since there are copious alternatives to model, a Design 
of Experiments approach was adopted to obtain data on several significant permutations 
with data extrapolation used to score effectiveness of some solutions. 

The project team performed a cost analysis and assessment of risk, both from 
aspect of vulnerability to operational threats and cost/schedule/performance 
considerations to all alternatives. A summary of the key findings along with areas for 
further research are included. 
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I. PROJECT INTRODUCTION 


A, PROBLEM STATEMENT 

Fleet Battle Management (FBM) teehnologies, taeties, proeesses and proeedures 
may benefit from the ineorporation of some of the “game ehanging” transformational 
teehnologies artieulated in the Chief of Naval Operations (CNO) Information Dominanee 
vision. However this vision has not been evaluated with systems engineering rigor. 
Proper evaluation requires the definition of measures of performanee (MOPs) and 
teohnieal performanee measures (TPMs) assoeiated with FBM sueeess, the identifieation 
of gaps or shortfalls in eurrent and programmed approaehes, development of suffieiently 
detailed arehiteetural alternatives, the eonstruetion of performanee models, and the 
performanee of high-level analyses and optimization of eandidate solutions for both 
eapability and Total Ownership Cost. 

This projeet examines the MOP, MOE, and Quality of Serviee (QoS) 
eharaeteristies required to support an Agile and Network-Centrie Command and Control 
organization. The speetrum of Doetrine, Organization, Training, Leadership, Materiel, 
Personnel, and Faeilities (DOTMLPF) eonsiderations will be examined. 


B, PROJECT SCOPING AND REFINEMENT 

This Capstone Projeet topie is a refined objeetive that took several iterations, 
divided below three major phases. 

1. Original Objectives 

The topie was seleeted to support the Deputy Chief of Naval Operations (DCNO) for 
Information Dominanee (N2/N6) roadmap effort. Under this effort, the DCNO has 
identified a set of 15 mission/eapability roadmaps: 
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Table 1 - Information Dominance Roadmaps [After Department of the Navy, 
Deputy Chief of Naval Operations for Information Dominance 2010] 


Undersea Dominance 

Integrated Surface Sensors 

Every sensor is networked 

Electromagnetic Spectrum 

Maritime Ballistic Missile Defense 

Command and Control 

Air Dominance 

Maritime Domain Awareness 

Strike Command and Control 

Intelligence, Surveillance, and 

Reconnaissance 

Decision Superiority 

Unmanned Aircraft Systems 

Spectrum Usage 

Cyber 

Convergence to a Single network 

Fleet Battle Management 



The topic of this Capstone will focus on the Fleet Battle Management capability, broadly 
defined as: 

“Derive a process and architecture that allows for optimal employment of 
resources. Include the ability to support C2 from the location that best 
meets mission needs, is responsive to changes in the operating 
environment and maintains commander’s intent.”(Department of the 
Navy, Deputy Chief of Naval Operations for Information Dominance 
2010 ) 

As partly shaped by Dr. Bill Rix from the Space and Naval Warfare Systems 
Command, the hypothesis that Fleet Battle Management (FBM) technologies, tactics, 
processes and procedures may benefit from the incorporation of some of the “game 
changing” transformational technologies articulated in the Chief of Naval Operations 
(CNO) Information Dominance vision has not been evaluated within the model based 
systems engineering framework and its accompanying rigor. Proper evaluation would 
require the definition of MOPs and TPMs associated with FBM success, the 
identification of gaps or shortfalls in current and programmed approaches, development 
of sufficiently detailed architectural alternatives, the construction of performance models. 
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and the performance of high-level analyses and optimization of candidate solutions for 
both capability and Total Ownership Cost. 

US Navy doctrine recognizes the key role Command and Control plays in the 
combat effectiveness of military forces. Naval Doctrine Publication 1 also relates the 
concepts of Command and Control with battle space dominance: 

“Modem battlespace is multidimensional. Navy and Marine Corps 
operations encompass air, surface, subsurface, land, space, and time. 
Dominance of these dimensions continues to be an important factor in the 
survival and combat effectiveness of our force. Command and control 
integrates ships, submarines, aircraft, and ground forces, so their full range 
of capabilities can be extended effectively throughout our 
battlespace.’’(Department of the Navy, Office of the Chief of Naval 
Operations 1994) 

In this same publication, the need for integrated Command and Control systems is 
discussed as an enabler for enhanced fleet battle management capability: 

“Integrating global C4I systems that directly link and support naval forces 
and joint forces will provide us an accurate picture of the battlespace. 

Some C4I operational capabilities include: enhanced battle management 
systems; fully interoperable, user centered, multimedia (voice, video, and 
data) links; embedded cryptographic security; and the ability to collect, 
evaluate, disseminate, and receive near-real-time, all-source, fused 
intelligence and surveillance data.”(Department of the Navy, Office of the 
Chief of Naval Operations 1994) 

As natural as it would seem to couple Naval Command and Control capability 
(and therefore fleet battle management) to communications and network capability, it is 
important to ensure that operational organization is considered as part of the problem 
domain. In a 1915 article in Proceedings, Commodore Dudley Knox (then a Lieutenant 
Commander) addressed this aspect in three-thousand word essay concerning naval 
doctrine, stating: 
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“Good leadership or eommand, as distinguished from administrative 
management, is then obviously a eardinal requisite to sueoessful military 
operations. It properly ineludes not alone the effieieney of the person in 
ehief eommand, but also that of the ehain of subordinate eommanders 
whieh theoretieally eonneets the mind of the ehief to eaeh individual in the 
fleet or army. Command implies eontrol and direetion by a leader; but 
before this is possible with a large number of units, they must be divided 
into groups, eaeh under the eommand of a subordinate leader. Eaeh group 
may be again similarly subdivided and eommanded, and if the foree be 
large it may be neeessary to repeat the proeess of subdivision many times. 

By means of sueh a so-ealled “ehain of eommand” it beeomes possible to 
earry into exeeution the will of the highest leader in a manner whieh eould 
not otherwise be done, and to ensure that the entire organization aets 
eoordinately and harmoniously as a unit.”(Knox 1915) 

This theme is also addressed in more reeent writings by the DoD Command and 
Control Researeh Program (CCRP) in their various publieations. In a reeent book 
addressing agile eommand and eontrol, it is noted that: 

“The ehallenge to the military is not so mueh to make its fighting 
struetures more networkable, sinee they are inherently so already, but to 
ensure that the way forees are eommanded and eontrolled, and polieies are 
formed, are eoherent and similarly adaptive and agile to the forees they 
eommand. Put simply, sueh eomplex systems eannot be eontrolled, and to 
attempt to do so would be to deny the network its fidelity, agility, and 
trusts to do the right thing.’’(Atkinson and Moffat 2005) 

2. First Level of Refinement 

A key eonsideration for the projeet team to understand how to refine the problem 
statement was to understand how the Navy has ehanged. Traditionally operational 
eommander would deploy naval Forees with little or poor eommunieations eapability. 
“Navy operational eommanders routinely have provided taetieal forees 
direetion and guidanee through a elear statement of eommander’s intent 
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that defines the “who” and “what, “explains the “why,” and establishes the 
boundary eonditions for the “when” and “where” taetieal aetion shall 
oecur. These Navy operational eommanders rely on the initiative of their 
subordinate eommanders to define the “how” the action will occur. It is 
expected that subordinate commanders will exercise initiative and act in a 
manner that does not depart unnecessarily from standard procedures, 
practices, or intrusions (i.e. doctrine) and satisfies the fleet commander’s 
stated intent while ensuring coordination with other elements of the 
force.’’(Department of the Navy, Office of the Chief of Naval Operations 
2008a) 

As the Naval force becomes networked, a new paradigm has emerged where the 
operational commander is now in a better position to balance risk and opportunities as 
well as virtually participate in the battle to provide value added direction and information. 
“The revolution in information systems and the rise of networked, globally 
connected forces has changed the command and control (C2) of forces in 
the traditional maritime domain. No longer is the maritime operational 
commander disconnected from tactical forces at sea. This new ability to 
reliably share information with tactical commander forces after they have 
commences acting on operational tasking opens new opportunities for the 
operational commander to define acceptable risk and to better integrate 
and synchronize force action in a maritime control area of operations 
(AO), OA, joint operations area (JOA), or theater operations.’’(Department 
of the Navy, Office of the Chief of Naval Operations 2008a) 

Research into the various aspects of communications and doctrine that help or 
hinder battle operations in the network environment is a rich area of study. The project 
purposely refined the topic down to research and evaluation of Network QoS required by 
tactical and operational commanders to accomplish netted C2 and battle management. 
Very simply, the focus became what is the QoS required for Navy networks to support 
the objectives of both the operational and tactical commander of networked naval forces? 
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3, Final Focus Areas 

The project team realized that there is a difference between characterizing design 
metrics for the network components and defining metrics for overall effectiveness of the 
networked force. In the web services community this is becoming more widely 
understood as Service Level Expectations or Quality of Experience. 

“...distinction between Quality of Experience (QoE) and QoS in the web 
environment, by pointing out that while QoS parameters are under full 
control of the service provider (e.g., throughput, server availability), QoE 
parameters, even if closely related to QoS parameter, may be influenced 
(i) by subjective elements related to user history and preferences, and (ii) 
by any system interposed between the provider and the user. ... the QoE 
of a user surfing the web using a browser through an Internet Service 
Provider is lightly affected by network latency and highly affected by 
network bandwidth.’’(Marchetti, Pernici, and Plebani 2004, 48-54) 

This project proposes a set of MOEs for networked forces that address the Quality 
of Experience or the Service Eevel Expectations (SEEs) of the operational and tactical 
commander to effectively exercise fleet battle management and command and control in 
a network centric environment. 
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II. PROJECT APPROACH AND DELIVERABLES 


A. PROJECT TEAM 

The project team consists of ten members with varied experiences and knowledge 
to offer to this capstone project. The members reside in two different geographical 
locations, six members from San Diego, California and four members are from 
Charleston, South Carolina. 

Roles and responsibilities were divided into Project Management and Systems 
Engineering categories as explained in Project Management and System Engineering 
plan. Appendix A. 

The original roles and responsibilities were initially assigned so that both geographic 
locations had similar roles. However, for efficacy and efficiency reasons, the roles and 
responsibilities were adapted to maximize local team productivity and to minimize the 
risk of schedule delays. The updated roles and responsibilities are below shown in Table 

2 . 


Table 2 - Project Engineering Roles 


Role 

Member 

Key Responsibilities 

Team Eead 

Stewart Hall 

• Act as single POC for Team 

• Eead Planning 

• Stakeholder Engagement and 

C ommunic ations 

Team Co-Eead 

Steve Roa 

• Act as Backup POC for Team 

• Assist Eead Planning 

• Assist Stakeholder Engagement and 

C ommunic ations 

Project 

Administration 

Nazila Rashed 

• Maintain Project Schedules 

• Monitor Critical Path Activities 

• Maintain communications 
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Project Risk 

Manager 

Adam Wolf 

Mike Shirley 

Charles Wood 

• Risk identification 

• Risk Analysis 

• Risk monitoring 

• Risk Reporting 

Librarian 

Ben McCoy 

Roger Gray 

• Maintain Sakai website 

• Maintain data repository 

• Configuration control of all deliverables 

Editing 

Fernando 

DeJesus 

Antonio 

Siordia 

• Assembly of Deliverables 

• Administer quality control 

• Ensure technical merit and cohesiveness 

Charleston 

Team POC 

Roger Gray 

• Act as primary POC for Charleston team 

to help with coordination 


In the next paragraph provides a description of the actual project structure and 
management philosophy 


B, PROJECT CYCLE 

To ensure success, the project team adopted a development cycle to organize 
progress as described in Visualizing Project Management. The project was divided into 
four broad phases: 

• research and problem refinement 

• architecture and analysis 

• form conclusions & recommendations 

• report results 

For each of these phases decision gates were incorporated giving opportunity to obtain 
feedback from stakeholders and NPS advisors. The status of the phases was presented to 
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the stakeholders at Interim Progress Report (IPR) sessions. Throughout the duration of 
the project, standard project management practices were employed such as: 

• Project Risk Management 

• Project Integrated Master Scheduling 

• Communications Planning 

• Collaboration and File sharing 

• Stakeholder communications 

• Issues Management 

• Configuration Management 

• Data Management 

In the end, this report provides recommendations, recommendations, and potential topics 
for future research. The complete Project Management and Systems Engineering Plan for 
this project is contained in Appendix A. The next paragraph describes the systems 
engineering plan and approach utilized by the project team. 
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Phase 1 

Research and Problem 
Refinement 

Phase 2 

Architectures Analysis 

Phase 3 

Form Conclusions & 
Recommendations 

Phase 3 
Report Results 


Figure 1 - Project Cycle 

C. SYSTEM ENGINEERING PROCESS OVERVIEW 

The team examined different systems engineering proeesses models to apply to 
this projeet. 

• Classie “V” model as taught in many Defense Aequisition University 
elasses 

• The arehitecture based approaeh deseribed in Steven Dam’s text on DoD 
arehiteeture framework (Dam 2006) 

• The INCOSE SIMILAR proeess modeled after the 7 classic systems 
engineering functions of seven tasks: State the problem, Investigate 


10 






alternatives, Model the system, Integrate, Launeh the system. Assess 
performance, and Re-evaluate (INCOSE 2006) 

• The system engineering approach proposed by Kossiakoff and Sweet in 
Systems Engineering; Principles and Practices (Kossiakoff and Sweet 
2003) 

The project team decided to base their SEDP on a tailored version of the approach 
proposed by Steven Dam. Eigure 2 illustrates the tailored process used for this project. 



Figure 2 - Project Tailored SEDP [After Dam 2006] 

The process steps are color coded to show their relation to the phases defined in the 
overall project cycle. The figure also demoinstrates start, completion, and duration in 
time for each process step. A brief discussion of the activities and products generated in 
each process step is provided in the following paragraphs. 

1, Step 1: Capture and Analyze Related Document 
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During this step, the project team researched available documentation to refine the 
problem statement. Documentation consulted included, Navy Warfare Publications, 
Tactical Techniques and Procedures, Universal Navy task lists. Chief of Naval 
Operations vision statements, technical journals, networking references and several 
banking industry resources. The project team goal was not only to ensure they understood 
the operational context but explored other sources in science and industry that could offer 
alternative approaches. 

2. Step 2: Identify Assumptions & Constraints 

During this step the project team consulted stakeholders and advisors to ensure 
the project scope was adequate. This process while was the second step initiated, was a 
process that continued throughout most of the system engineering activities. The project 
team remained in contact with stakeholders and advisors to ensure buy-in an assumptions 
and constraints. 

3. Step 3: Develop the Operational Context 

Steven Dam recommends drafting the operational context early and so does this 
project team (Dam 2006). The operational context grew, morphed, and changed shape 
numerous times during the project execution. 

4, Step 4: Develop Value System 

During this step, the project developed a set a weighted measures to be used to 
rank options. Operational requirements and interchanges with fleet stakeholders derived a 
set of measures. A numerical method was employed to rank the measures according to 
user’s perceived value. 

5, Step 5: Develop Effective Need Statement 

During this step, the project team synthesized research findings and requirements 
to form a revised problem statement (Miller 2009). This statement would continue to be 
revised based on understanding and findings from practically the entire system 
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engineering effort. In effeet the final effeetive need statement beeame the embodiment of 
all of the researeh and analysis performed. 

6, Step 6: Develop Operational Scenarios 

Dam describes in his book the challenge with deciding what specific scenarios 
should be used to perform analysis (Dam 2006). The project team had to continually 
debate this as there was a tendency to want to build complex and realistic scenarios to 
understand the behavior of the operational nodes and systems involved. The team had to 
continually ask itself the following questions: 

• What am I trying to understand? 

• What will my data show 

• Will this data provide any information that helps to discriminate between 
options? 

The project team employed a Design of Experiments approach to limit scope and 
complexity of scenarios to be used in the analysis. 

7, Step 7: Perform Functional Analysis 

Steven Dam describes this step as the “art of system engineering” (Dam 2006). In 
this step the project team created Function Flow Block Diagrams (FFBD) to define the 
functional activities at each operational node. FFBD were chosen primarily because the 
documentation available described the operational task in terms of activities to be 
performed, and not data transformation. The other aspect is that once these FFBD were 
created, the project team could simulate the operational requirements using the Vitech 
COREsim toolset. 

8, Step 8: Propose Options 

Typically this process looks to provide one or more options at the very end of the 
project. This project is no exception in that they are provided (finally) at the end. 
However to limit overly zealous analytical excursions on such a broad topic, intermediate 
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results for the functional analysis step were used to shape and define the necessary set of 
options that would be explored in follow-on modeling efforts and trade-off analysis. This 
allowed the project team to begin on the final analysis products as a parallel effort. This 
decision was not without calculated risk as the parallel efforts could diverge. 

9, Step 9: Perform Dynamic Analysis 

During this step the project team looked at how well each of the proposed 
alternatives would perform based on a projected use of fleet resources (in this case a 
combination of network and satellite communications capacity). The team used a 
comparative analysis technique to avoid issues of data classification since discussing 
actual communications capacity and actual traffic would potentially be disclosing fleet 
capabilities and limitations. This step was be used to define “goodness” of each 
alternative relative to the customer value system. 

10. Step 10: Conduct Trade-offs 

In the final step of the SEDP, the team evaluated effectives based on the value 
system against cost and risk to make final recommendations 

D, PROJECT STAKEHOLDERS 

Stakeholders were chosen because of their interest in DCNO investment strategies 
for Fleet Battle Management. Stakeholders included members of both the operational and 
acquisition community. Table 3 identifies the stakeholders consulted and their respective 
roles relative to the Capstone team. 


Table 3 - Project Stakeholders and Roles 


Stakeholder 

Interest 

COMPACFLT (N6) 

Overall Findings 


Functional Models 


Value System 
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US Navy CyberForces (N8) 

Overall Findings 

Fifecycle Cost Estimation 

Value System 

OPNAV N2N6F42 

Study customer 

Overall Findings 

Fifecycle Cost Estimation 

DASN C4I 

Overall Findings 

Fifecycle Cost Estimation 

PEO C4I 

Overall Findings 

Fife Cycle Cost Estimates 

SPAWAR5.0 

Overall Findings 

Functional Models 

Topics for Future Research 


The stakeholders were consulted via e-mail, telephone, and face-to-face 
discussions to establish the baseline representation of current implementations of 
situation awareness information distribution architectures. The relative merits and 
perceived merits of various alternatives were also discussed. In addition to the interaction 
with these stakeholders, information was gathered from numerous published articles and 
documents. 

The next paragraph outlines the expected project deliverables that will be 
provided to stakeholders, advisors and NFS during the course of the project. 

E. PROJECT DELIVERABLES 

The team established conclusions and recommendation based on observations 
from the models and a review of the life cycle costs associated with each model. 

Consequently, the associated deliverables for this project are as follows: 

• System Engineering/Project Management Plan 

• Project Schedule 

• In-Progress Review I Briefing materials 
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In-Progress Review 2 Briefing materials 
CORE models of the As-Is and To-Be funetional arehiteetures 
JCSS Models of the As-Is and To-Be Physieal Arehiteetures 
Summary Report of Researeh and Analysis 



III. RESEARCH PHASE - BASIC RESEARCH 


A, NAVY TASK LISTS 

The project team researched Navy tasks applicable for command and control in 
the Universal Naval Task List (Department of the Navy, Office of the Chief of Naval 
Operations 2008b). The UNTLS provided valuable insight to how specific measures are 
developed to measure mission success. The following tables are digests of applicable 
UNTLs: 


Table 4 - NTA 5.1.1 Communicate Information 


1 

Percent 

Of the time, subordinate commanders in communication with 
OTC during execution. 

2 

Minutes 

Lag between the commander’s common picture of the battle 
space and real world. 

3 

Percent 

Of time, desired communications path available. 


Table 5 - NTA 5.1.1.1 Transmit and Receive Information 


1 

Percent 

Of the time, subordinate commanders in communication with 
OTC during execution. 

2 

Minutes 

Lag between the commander’s common picture of the battle 
space and real world. 


Table 6 - NTA 5.1.1.1,1 Provide Internal Communications 


1 

Percent 

Of time, desired communications path available. 

2 

Minutes 

Lag between commander’s common picture of the battle space 
and real world. 

3 

Percent 

Link data efficiency. 


Table 7 - NTA 5,1,1.1.2 Provide External Communications 


1 

Minutes 

Without communications path to higher authority during 24 
hour period. 

2 

Percent 

SIPRNET communications accessibility. 


Table 8 - NTA 5.1.1,1,2.1 Receive and Transmit Force Orders 


Percent Of addressees received messages. 
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2 

Percent 

Of the time, subordinate commanders in communication with 
OTC during execution. 

3 

Percent 

Of time, desired communications path available. 


Table 9 - NTA 5,1.1.1.2,2 Relay Communications 


1 

Number 

Messages relayed. 

2 

Minutes 

To relay required messages. 

3 

Percent 

Correct messages received. 


Table 10 - NTA 5.1.2 Manage Means of Communicating Information 


1 

Percent 

Of C4I resources required to support force redeployment 
identified. 

2 

Percent 

Of time, force maintained voice and data communications 
(unsecure and secure). 

3 

Percent 

Of C2 nodes have all required communications capabilities. 


Table 11 - NTA Mapping to Value Elements 


NTA 

Value Element 

5.1.1 

Provide Effective SA over the Network 

5.1.1.1 

Provide Operational Quality SA 

5.1.1.1.1 

Provide Tactical Quality SA 

5.1.1.1.2 

Maintain Suitable Network Reliability 

5.1.1.1.2.1 

Provide Tactical Command 

5.1.1.1.2.2 

Provide Tactical Quality SA, Provide Tactical Command 

5.1.2 

Provide Network Availability, Provide Network Survivability 


These UNTLs, were used latter in the SEDP to ereate a value system and 
functional model for performing network Agile C2. The next paragraph discusses how 
the Common Operational Picture capability is key technology for maintaining C2 in the 
seam between Navy operational command and tactical command 


B, COMMON OPERATIONAL PICTURE 

The Common Operational Picture (COP) is the key situational awareness tool for 
Naval operational commanders. From the Global Command and Control System 
Common Operational Picture Reporting Requirements: 

“[CJommon operational picture - 1. The common operational picture is a 
distributed data processing and exchange environment for developing a 
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dynamic database of objects, allowing each user to filter and contribute to 
this database, according to the user’s area of responsibility and command 
role. The common operational picture provides the integrated capability to 
receive, correlate, and display a common tactical picture, including 
planning applications and theater-generated overlays and projections (i.e., 
environmental, battle plans, force position projections). Overlays and 
projections may include location of friendly, hostile, and neutral units, 
assets, and reference points. The common operational picture may include 
information relevant to the tactical and strategic level of command. This 
includes, but is not limited to, any geographically oriented data, planning 
data from Joint Operation Planning and Execution System, readiness data 
from Global Status of Resources and Training System, intelligence 
(including imagery overlays), reconnaissance data, environmental (air, 
land, sea, and space), predictions of nuclear, biological, and chemical 
fallout, and air tasking order data. 2. A single identical display of relevant 
information shared by more than one command. A common operational 
picture facilitates collaborative planning and assists all echelons to achieve 
situational awareness.” 

From the same document, the significance of the role of the COP was described as: 
“COP is a distributed data processing and exchange environment for 
developing a dynamic database of objects, allowing each user to filter and 
contribute to this database according to the user’s area of responsibility 
and command role. It is a key tool for commanders in planning and 
conducting joint operations and in monitoring execution and coordinating 
joint operations across combatant commands. The COP enhances the flow 
of information among the Secretary of Defense, Joint Staff, and combatant 
commanders (CCDRs), both supplementing and amplifying theater 
commander’s situation reports (SITREPs), operational reports (OPREP), 
and other reports outlined in reference a. The COP is a tool for sharing 
critical standing and situation dependent information across combatant 
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commands to achieve sueeess in the speetrum of operations.’’(Department 
of Defense, Chairman of the Joint Chiefs of Staff 2008) 

The next seetion diseusses how navy afloat taetieal eommanders must rely on the 
Navy satellite eommunieation systems to maintain network eonneetivity 

C. NAVY SATELLITE COMMUNICATIONS SYSTEMS 

The projeet team researehed naval eommunications and network arehitectures. In 
the maritime environment, naval units rely heavily on satellite eommunieation link to 
prove TCP/IP transport for COP database interactions. Figure 3 illustrates the significant 
touch points of COP traffic between ashore and afloat nodes. 



Figure 3 - Ashore to Afloat Communication Nodes 

The operational eommander at the Maritime Operations Center (MOC) is 
eonneeted to other Joint operational nodes and eoordinating ageneies typieally through 
terrestrial networking systems. Communieations between the operational eommander and 
the CTF eommanders oecurs over SATCOM. For this traffie, the information travels 
from the MOC through a Network Operations Center (NOC) to a Naval Computer and 
Teleeommunieations Area Master Station (NCTAMS). More detailed Operational Event 
Trace Diagrams are provided in Appendix E. 


20 






The next paragraph summarizes research finding from the financial industry. 
Interestingly enough, world banking systems treat processing delays as risk. The project 
team researched into how banking and financial systems mange transaction delay and if 
this could be applied to fleet battle management. 

D, RESEARCH INTO BANKING ARCHITECTURE 

Several research paths/cycles in defining Command and Control (C2) and 
defining Fleet Battle Management (FBM) led the team to examine the applicability of 
industry information transfer models to Quality of Service (QoS) requirements and 
implications for Agile C2. This report examined the banking industry, known for its 
exacting command and control requirements, specifically real-time gross settlement 
systems. For ease of exposition, the Bank for International Settlements definition follows: 
“A Real Time Gross Settlement (RTGS) System can be defined as a gross 
settlement system in which both processing and final settlement of funds 
transfers (based on instructions received from payer bank/institution) takes 
place continuously (i.e., in real time). As it is a gross settlement system, 
the transactions are settled individually without netting debits against 
credits. As it is a real time settlement system, the final settlement of funds 
is effected by the system continuously rather than periodically at pre¬ 
specified times.” (Lucas 1997) 

Additional background on this follows in the Research in Banking Models section. The 
RTGS method defines four alternative transaction methods based on different needs and 
situations. They are referred to as: V, Y, T and L Shaped transaction methods. Figures 1, 
2, 3 and 4 define these methods respectively 
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Figure 4 - V-Shaped RTGS System [From Lucas 1997] 


These methods eould be applied to maritime MOC/ Strike group/ or unit of action 
type of framework for purposes of modeling analysis. Further, these methods may also 
map to queuing processing models FIFO or priority processing schemes and their overall 
effect across the battle force. By discussing how services can scale to improve QoS and 
to optimize available resources by varying membership categories, a game-changing 
strategy may emerge. 


22 
















Figure 5 - Y-Shaped RTGS System [From Lucas 1997] 


X-shaped 

1. full paymetit 
message 



Figure 6 - T-Shaped RTGS System [From Lucas 1997] 
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Figure 7 - L-Shaped RTGS System [From Lucas 1997] 

As noted in the literature: 

“Interbank payment and securities settlement mechanisms are the main 
facilities for transferring monetary claims and assets between financial 
institutions. These systems transfer many times the value transferred by 
cash instruments or retail payments. The infrastructure has gradually 
grown into a complicated interactive network of systems that transfer 
claims and assets at the domestic and international level. Integration of 
these systems has resulted in critical interdependencies.” (Lucas 1997) 

Given a global economy that still depends on local economic customs and process 
organization patterns, technical solutions depend on a wide variety of configurations. An 
important parallel can be drawn between the wide variety of payment systems suited for 
specific transaction flows for a particular state and current Navy Command and Control 
Operational network topology and mission operational constructs. Different network 
topologies are more suited to specific mission threads just as transaction processing 
systems are more suited to specific transaction flows. 

Suitability and efficiency vary for different financial systems and transaction 
depending on both time and specific geographic region. Similar problems are faced for 
measuring operational effectiveness of Navy C2 systems using existing traditional 
analysis techniques and models. These techniques and models tend to be too general and 
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often discuss less important systems’ parameters, making them inadequate to fully 
capture current Navy C2 DOTMPLF for various operational mission threads. 

Many of the same problems faced by central banks apply to Navy Command and 
Control. Using a hierarchal approach to C2 as discussed in Vice Admiral Willard’s paper, 
the pace of C2 at lower operational levels should not be constrained by higher levels 
unless absolutely necessary. The same construct is true in bank-settlement and payment 
processing systems for various countries. This tiered system depends on a small number 
of large banks to settle on the books of a central bank, yet a large number of small 
intermediary banks settle with the facilities of the larger banks. This multi-tiered 
structure for small banks adds processing layers and risk just as the tiered concept to the 
common operational picture adds risk to the speed of and effectiveness of Navy C2. 
Current research into flat network-based processing structures show that modern 
technology can reduce the risk for financial settlement systems. The flat or “common” 
operational picture used in bank settlement systems may reduce overall risk and provide 
and increased speed of C2. 

As noted earlier, payment and settlement systems tend to be hierarchal in 
structure. Different transactions are handled by different systems. To reduce overall 
institutional risk and liquidity needs, a central bank can be considered as the real-time 
gross settlement system between various banks. Transaction flows between banks are 
processed by the central bank settlement system that provides an overall “common” risk 
picture for both the large and small banks. 

With a hierarchal system that integrates inputs from several different transaction 
types, transactions from one system have to be integrated and processed in another 
system. Synchronization quickly becomes a problem as transactions flow between 
various hierarchies and systems. The same approach applies to current Navy C2. 
Synchronization becomes a problem between the COCOM and CTF as information flows 
between various levels making it difficult to obtain a common operational picture. 

In the figure below a participant inputs a transaction into the settlement system 
which books and queues it for further processing. However, with a hierarchal system, 
many thousands of the similar transactions are occurring at the same time, creating the 
necessity for gridlock resolution. 
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Figure 8 - Notional Settlement System [From Leinonen 2005,19-23, 31-32] 

Applying the concept of a flat network structure to settlement processing allow 
for reduced liquidity risk for the entire system through more efficient gridlock resolution. 
For our purposes, a flat common operational (COP) picture will increase the speed of 
decisions through the centralization of the tiered COP databases from various command 
levels to a central location. Each command level will synchronize with a common COP 
database located at the Networks Operation Center. 

E. FINDINGS FROM BASIC RESEARCH PHASE 

The project team basic research yielded several significant findings that were 
applied to systems engineering process. 

1, Navy Task List Findings 

Research in to UNTLs used to measure Command and Control mission success 
showed that information delay was a key measurement parameter. Other important 


26 












































parameters ineluded quality of eommunieations eonneetivity at what degree messages are 
eorrectly transmitted and reeeived. 

2. Common Operational Picture 

An important finding was how the COP provides a key eommand and eontrol 
eapability in the seam between operational and taotieal eommand. 

3. Satellites Communications Systems 

One of the researeh findings of the projeet team is that the Navy relies on 
SATCOM for network eonneetivity between operational and taotieal oommanders. This 
finding is signifioant in that any meaningful analysis may need to aooommodate satellite 
oommunication system performanoe and not just network performanoe. It is possible that 
the current Navy satellite communications architecture may be a limiting factor in how 
well network centric command and control performs (and not the networks themselves). 

4. World Banking Systems 

One of the research findings of the project team is that the current information 
architectures and data transfer mechanisms employed in theater situational awareness can 
benefit from the application of architectural characteristics used in the banking industry. 
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IV. RESEARCH PHASE - PROBLEM REFINEMENT 


A. ASSUMPTIONS AND CONSTRAINTS 

A series of assumptions were made to minimize the complexity of the 
examination of the problem space and allow for a more in-depth analysis and review of 
the hypothesis. 

1. Cognitive Aspect of Fleet Battle Management 

The capstone team recognized that there is a cognitive aspect to the analysis of 
interactions and information flows in Fleet Battle Management, however, because this 
investigation was focused primarily on the functional and physical interactions and data, 
flows, it was assumed that the cognitive aspects would have a mutually cancelling effect 
when conducting comparisons of the results. While this is truly a worthwhile topic of 
research it was decided in consultation with stakeholders and project advisors, this would 
be beyond the scope of our analysis. 

2, Notional Functional Analysis 

A fundamental assumption made in the development of the As-Is model affected 
the functional interactions between the various echelons of command. NWP 3-32 does 
not describe in detail the specifics of the various interactions. In addition it is recognized 
that the details of the interaction, timing, and exactly “who” in the networked needs to 
interact with “who” to accomplish: what” varies greatly on missions and adversary. 
Therefore, using available subject sources such as VADM Admiral Willard’s seminal 
article in Proceedings and requirements in NWP 3-32, a notional interaction flow was 
developed in CORE and used as the basis for building the functional modeling and 
analysis (Willard 2002). 

In addition to avoid concerns of data classification, each of the functions was 
assigned a default execution by the modeling toolsets time with a Gaussian distribution to 
minimize the variability of the effects of the information exchanges in the model. 
Whenever functions occurred at different echelons of command or modes in the 
operational architecture, the function was assumed to have a similar execution time in all 
instances (other than the random execution time assigned by the model). The treatment of 
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the functions in this manner was not deemed to have a skewing effect on the outcome, 
primarily because this was a comparative exercise. An additional series of assumptions 
were made regarding the serial nature of the interrelated processes executing in each of 
the echelon’s command and control cycle. Another assumption made was that the 
execution process in the tactical environment would be allowed to run with minimal 
intervention from the oversight echelons. 

3, Abstracted Details of Physical Networks 

The physical network implementation was modeled assuming consistency in 
implementation of the network at each of the nodes modeled. That is, each node was 
assumed to have the same types of equipment and that each of the communication links 
had relatively constant throughput. These assumptions allowed the team to more readily 
observe the effects of various discrete component changes in an isolated fashion. 

4, Tactical versus Operational Level of War 

For the analysis step, the project team decided to concentrate on the tactical 
operational level war overlap. The reasons for this were that in the tactical domain, the 
networks and information exchange requirements begin to address weapons and effects. 
This was considered outside the scope of fleet battle management. Conversely, at the 
other end of the spectrum are information requirements addressing strategic and 
operational planning. The project team decided that while exploration of these concepts 
could be interesting, it most likely would not meet the stated need of the stakeholders. 

5, Cost Data 

To the maximum extent possible, the project team based cost estimates for 
lifecycle costs using existing programs under the DCNO portfolio of information 
dominance programs as analogous systems. 

B, OPERATIONAL CONTEXT 

An operational context for fleet battle management could easily become quite 
complex. Given the accepted project constraints and assumptions, the project team 
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adopted a simplified eontext for this project. The context is illustrated in the OV-1 
diagram shown in Figure 9. 



Figure 9 - OV-1 Diagram 

In this Operational View a Combatant Commander stands up a Commander Joint 
Task Force (CJTF) in response to a theater situation. The CJTF then stands up a Joint 
Forces maritime Component Commander to support naval operations. The JFMCC is 
embarked ashore at the Maritime Operations Center. The JFMCC activate three 
Combined Task Force (CTF) Commanders for the tactical operations. The CTF 
commanders are assume to be afloat. 

The physical communications and networking architecture need to be considered. 
The CJTRF and JFMCC are assumed to be ashore and connected with terrestrial 
networking systems. Communications between the JFMCC (located ashore at the MOC) 
and the CTF commanders occurs over SATCOM. For this traffic, the information travels 
from the MOC through a Network Operations Center (NOC) to a Naval Computer and 
Telecommunications Area Master Station (NCTAMS). More detailed Operational Event 
Trace Diagrams are provided in Appendix E. 
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C. VALUE SYSTEM DEVELOPMENT 

The value system design began with the effeetive need of providing networked 
agile eommand and eontrol. The proeess began with researehing the US Navy’s current 
capability including: Maritime warfare, tactics tips and procedures, current command and 
control infrastructure and current status of becoming a network-centric warfighter. After 
the research, the value system was broken down into two subcomponents. Provide 
Effective Situational Awareness over the Network and Maintain Suitable Networks 
Reliability. These encapsulate the primary functions that must be achieved in order to 
provide networked agile command and control. Since operational decisions happen at a 
different rate then tactical decisions, the value hierarchy further breaks down to consider 
the operational commander’s timeline and the tactical commander’s timeline. 



Figure 10 - Value Hierarchy 
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The following paragraphs describe how the project team was able to derive 
objective and threshold values from user needs and requirements. In addition the process 
for defining the weights will be described. The weights were used as part of the decision 
analysis process that will be discussed in paragraph VII. Further, it should be noted the 
weights in Figure 10 do not add to 100 due to rounding errors. Table 13 that follows in 
later paragraphs will have the more precisely calculated weight values. 

1, Operational Situational Awareness 

Chairman of the Joint Chiefs of Staff Instruction 3151 address the need for timely 
situational awareness to be provided in the Common Operational Picture and was used to 
help establish the value system. 

“The information that the COP displays is time sensitive. The definitions 
of real time, near real time, and non-real time serve to provide a 
commander a sense of the value of information. Delays due to data 
processing, slow communications networks, or any other transparent 
delays can further degrade the value of information. Track managers and 
operators should understand the time value of data being displayed on the 
COP and communicate this to the commanders.’’(Department of Defense, 
Chairman of the Joint Chiefs of Staff 2008) 

The challenge has been (and remains today) how to define timely situational 
Awareness threshold and objective values. This is also compounded by the fact that this 
can be dependent on several factors including, mission need and physics of the sensors 
themselves. Understanding Information Age Warfare Alberts (et al) write: 

“For example, tolerable latency may be seconds (missile defense), minutes (outer 
air battle), hours (logistics close to the front), days (theater logistics), or weeks 
(mobilization). Commands often establish standards for latency depending on the 
physical limits on information capture and processing, the physics of the mission 
area, their organizational capacity, and other factors.’’(Alberts et al. 2001) 
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CJSI 3151 address the objective latency requirements for the Common 
Operational Picture in Table 12, shown below. For operational command, the objective 
track latency varies from 6 hours to 3 minutes depending on type of information (air 
tracks, surface tracks, etc). To simplify the derived value system, the project team used 
the most conservative latency for 3 minute as the objective value for operational 
situational awareness. 


Table 12 - Desired Track Latency [From CJSI 3151] 


DOMAIN 

FRD 

AFD 

NEU 

sus 

HOS 

UNK 

PND 

Surface 

15 min 

4 hours 

6 hours 

24 hours 

24 hours 

6 hours 

0 

Subsurface 

6 hour 

6 hours 

6 hours 

24 hours 

24 hours 

6 hours 

0 

Conventional 

Land 

4 hours 

4 hours 

4 hours 

24 hours 

24 hours 

2 hours 

0 

Air 

3 min 

3 min 

3 min 

3 min 

3 min 

3 min 

0 

SOF 

4 hours 

N/A 

N/A 

N/A 

N/A 

N/A 

0 

TBM (special) 

0 

0 

0 

6 hours 

6 hours 

6 hours 

0 


2, Tactical Situational Awareness 

The values for tactical situational awareness were based on Link-16 performance. 
While actual track latency over Link-16 will vary with factors such as number of 
participating units, range of the network, track load, etc. the basic network cycle time is 
12 seconds (Department of the Navy, Navy Center for Tactical Systems Interoperability 
1996). This metric was used to form the basis for the value hierarchy. 

3. Operational Command 

The threshold and objective values for operational command were based on the 
values established for situational awareness. Threshold was based on minimum latency 
value for tracks with an objective set to coincide with the minimum cycle time for link-16 
networks. 


4, Effective Command (Tactical Quality) 

The measures for effective tactical command have been traced to the ability o 
meet hard time deadlines for employment and coordination of weapons and effects. The 
exact time figures are dependent on mission, sensor, weapon, effect, etc. To mitigate any 
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concerns with data classification due to exposing navy eapabilities and limitations, the 
projeet team ehose to discuss this measure as a pereentage of overall time that real-time 
deadlines are met and the pereentage of time prioritization of data is eonserved. 


D, VALUE SYSTEM WEIGHTS 

The weighting for the value system in Table 13 was developed using the swing 
weight method deseribed in Making Hard Decisions with Decision Tools. (Clemen and 
Reilly 2000). To ensure the value system reflects the fleet users, a seleet group of users 
with command and control expertise were selected to evaluate the value of a C2 network 
as eaeh measure was varied from objeetive the threshold value. Table 13 below re fleets 
the fleet stakeholder raw seores and the normalized weights ealeulated for the value 
system. 


Table 13 - Value System Weights 


Value System Measure 

Stakeholder Assessment 
of Value (expressed 
value in range of 1-10) 

Caleulated 

Normalized 

Weight 

Operational Situational Awareness 
set to objeetive value; all other at 
threshold 

9 

0.209302326 

Tactical Situational Awareness set to 
objeetive value; all other at 
threshold 

9 

0.209302326 

Operational Command set to 
objeetive value; all other at 
threshold 

8 

0.186046512 

% For Soft Real-Time eonstraints 
met set to objeetive value; all other 
at threshold 

8 

0.186046512 

% For Hard Real-Time eonstraints 
set to objeetive value; all other at 
threshold 

9 

0.209302326 


The next section briefly deseribes the researeh into threats that projeet team 
eonsidered as part of the problem refinement proeess. 


34 




E, THREAT ANALYSIS 

Due to overall coneerns of data classification, the project team is unable to 
provide a detailed threat analysis. However, there are well known themes that are widely 
documented in public press that can be (and should be) applied to this problem statement. 

1, Cyber Attacks 

As the number of wireless systems continues to grow, and as digital systems 
began to gain more capabilities, the amount threats to the U.S. information technology 
infrastructure will continue to grow. Currently, factors such as associated costs, perceived 
need, operational requirements, and regulatory constraints, have made it difficult for 
network defense technologies to keep up with the frequent occurrences of cyber attacks 
(Blair 2010). The vulnerability of DoD networks and commercial transport backbones 
represent a threat to networked fleet battle management 

2, Protected Systems 

Whether the users of the military satellite communications systems are on ships, 
aircraft, or land vehicles, the architecture they use are protected by accept very low to 
moderate data rates in exchange for considerable protection of their links against 
physical, nuclear, and electronic threats. These systems that are protected in this 
architecture are the Mil-star system. Air Force Satellite Communications (AFSATCOM) 
and extremely high frequency (EHF) payloads (Martin 2002). In general Navy networked 
forces may need to be able to perform effectively with the limited capacity satellite 
communications 

3, Budget Cuts 

Being that the national security part of the federal budget has been predicted to 
suffer budget cuts; the Navy will most likely feel the brunt of this effect. The number of 
ships the Navy currently has is 285. The goal and previous commitment of having a 313 
ship Navy, made by the DoD, has not been reached yet. U.S. Navy platforms will 
continue to decrease in number unless budget priorities realign with national security 
interests. Reducing the force will cause additional hardships, causing an increase in 
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operational and maintenance costs. If the Navy continues to not get the support and 
funding it needs, then the ideal of other nations challenging U.S. Naval Supremacy can 
become a reality (Berube 2010). As decision makers balance the need for ships versus 
networking, it’s likely that investment in networking will see a decrease as historically it 
has been easier to defend combat effects using numbers of platforms and weapons than it 
has been top defend effectiveness of networking ability. 

F. EFFECTIVE NEED STATEMENT 

Net centric warfare poses a new series of challenges and issues in the execution of 
Agile Command and Control. In his paper to the World Congress of Engineering and 
Computer Science in 2008, Amir Shamdani establishes a thematic view of Agile 
Command and Control that is further reinforced by ADM Willard’s Naval Proceeding’s 
article albeit in an organizational context (Shamdami 2008). In his presentation, Mr. 
Shamdami postulates that Agile Command and Control is characterized by the following: 

• Developing common Situational Awareness across all participating nodes. 

• Developing collaborative planning based on commander’s intent. 

• Conducting concurrent planning and execution. 

While these activities are recognizable under traditional Command and Control 
paradigms, the project team submits that what changes in Agile Command and Control 
are the timelines under which each aspect is conducted as well as the iterative nature of 
activities 2 and 3 above. A conclusion that Mr. Shamdami establishes in this paper, is the 
need to recognize that Net-centric warfare and Agile C2 also rely on the cognitive 
architecture associated with the network, communications, and computing architecture. 
Effective Command and Control as described by VADM Willard in his Naval 
Proceeding’s article and NWP 3-32 also recognizes this need, but establishes more 
emphasis on a robust and agile organizational information-exchange architecture. This 
architecture must be also flexible to support the continuous nature of the C2 cycle and the 
required interaction across echelons that are paramount for agile C2. 

Discussions with stakeholders from the SPAWAR Chief Engineer’s office 
established needs as articulated in the following excerpt: 
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“Fleet Battle Management (FBM) teehnologies, taeties, proeesses 
and proeedures may benefit from the ineorporation of some of the “game 
ehanging” transformational teehnologies artieulated in the Chief of Naval 
Operations (CNO) Information Dominanee vision has not been evaluated 
with systems engineering rigor. Proper evaluation requires the definition 
of MOPs and TPMs assoeiated with FBM sueeess , the identifieation of 
gaps or shortfalls in eurrent and programmed approaehes, development of 
suffieiently detailed arehiteetural alternatives, the eonstruetion of 
performanee models, and the performanee of high-level analyses and 
optimization of eandidate solutions for both eapability and Total 
Ownership Cost .” [emphasis added] (Rix 2010) 

This statement establishes a need within the Navy to identify and implement not 
only the teehnologies and systems required to better implement Fleet Battle Management, 
but also the meehanisms to measure, test, and optimize the implementations and 
investments made to support this effort. 

Although these needs eomprised the primary foeus for this projeet, there are other 
stakeholder needs that must be aeeommodated to support the effeetive implementation 
and sustainment of the needed warfighter eapability. These additional needs address the 
need to aeeommodate other influenees and threats affeeting Navy systems. 

The need for these system eapabilities must be balaneed with the needs of a 
eonstrained fiseal environment, that is, the end solution must be affordable. The life 
eyele eosts for this implementation must not exeeed available budgets, and eare must be 
taken to ensure these eapabilities ean indeed be aequired. In addition to ensuring that the 
solution implementation does not overwhelm fiseal budgets, it must not overwhelm 
available personnel and skill sets. System eomplexity for operations and maintenanee 
must be abstraeted from the operators and maintainers to minimize the effeets of 
introdueing large-seale eomplex systems to the Fleet. 
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V. FUNCTIONAL ANALYSIS 


A. BASIS FOR FUNCTIONAL MODEL 

To better understand the operational interaetions for fleet battle management, a 
funetional model was constructed using Vitech Core. Determination of authoritative 
sources for Command and Control requirements is not a straightforward task. Among 
Naval Commander and watch standers the opinions are varied. This is due to many 
factors: experience and training, mission specifics, and theater specific practices, are just 
a few examples. In order to complete the project in a timely manner, several references 
were employed to aid in the development of the functional architecture. These references 
look at the practice of C2 from different perspectives but are surprisingly harmonious 
with respect to articulation of functions and tasks. 

• “Rediscover the Art of Command & Control” by Vice Admiral Robert 
F. Willard, U.S. Naval Institute, Proceedings, October 2002 

• Navy Tactics, Techniques, and Procedures - Navy Tactics, 
Techniques, and Procedures, NTTP 3-32.1 

• OPNAVINST 3500.38B/MC03500.26AAJSCG COMDTINST 

3500.IB, Universal Naval Task List (UNTL) 

• Understanding Command and Control by David S. Alberts and 
Richard E. Hayes, DoD Command and Control Research Program 
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Figure 11 - Overarching Guidance Flow to Systems Engineering 

It’s important for the reader to understand that there is a signifieant difference 
between functional requirements for Command and Control and Functional requirements 
for command and control systems. Fleet Battle Management is a human activity and such 
communication systems, networks, and command and control systems all support the 
commander’s activities. This analysis is not concerned with behavior of the command 
and control systems, rather the affect on fleet battle management by the human functions 
themselves. 

B. DESCRIBING THE MODEL’S OPERATIONAL CONTEXT 
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Understanding the interaetions of Command and Control funetions vertieal along 
eehelon of eommand and horizontally along breadth of eommand is a key eomponent to 
forming potential investment approaehes for network eentrie fleet battle management. 
Figure 12 from NTTP-3-32 illustrates this interaction as a series of decision cycles 
working at various echelons of command simultaneously. 



Figure 12 - Decision Cycles [From Department of the Navy, Office of the Chief of 
Naval Operations 2008] 


A simplified operational context is illustrated in Figure 13 and forms the basis of 
the simulation design. For this context, a Combined Joint Task Force Commander 
(CJTF) with battle watch staff is stood up ashore to command a maritime operation. 
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Supporting the CJTF is a Joint Forces Maritime Component Commander (JFMCC) 
embarked at a shore based Maritime Operations Center (MOC). Supporting the JFMCC 
is one to three Naval Combined Task Commanders (noted as CTF One, CTF Two, and 
CTF Three respectively). As operations commence Command and Control cycles as 
illustrated in NTTP 3-32.1 are activated at each command. 



Figure 13 - Simplified Operation Context C2 Simulation 


C. EXPLORING ALTERNATIVE OPERATIONAL CONTEXTS 
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In addition the simulation of the Command and Control architeeture as defined in 
NTTP-3-32 the project also simulated the functional behavior utilizing the clearing house 
construct to coordinate command and situational awareness across the battle 
organization. Figure 14 illustrates the simplified operational context for this approach, in 
which a Combined Joint Task Force Commander (CJTF) with battle watch staff is stood 
up ashore to command a maritime operation just as before. 




CJTF 


1 


CTF One 


1 


1 


CTF Two 




MOC 



1 


CTF Three 


Figure 14 - Simplified Operation Context for Clearing House C2 Simulation 

CJTF is a Joint Forces Maritime Component Commander (JFMCC) embarked at a 
shore based Maritime Operations Center (MOC). Supporting the JFMCC is one to three 
Naval Combined Task Commanders (noted as CTF One, CTF Two, and CTF Three 
respectively). What is different in this approach is that all nodes are interacting with a 
single Command and Control cycle. 

D. ASSUMPTIONS AND LIMITATIONS OF THE FUNCTIONAL MODEL 

While this model was very useful in providing insight into operational 
architectures for command and control and Fleet Battle Management, the project team 
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would like to point out the major assumptions and limitations of this model in order to 
ensure that readers of this research can accurately apply these findings. 


1. Notional Task Durations and Notional Data 

Due to concerns with classification of the overall modeling effort, the functional 
model intentionally uses notional data exchanges and does not account for actual message 
data (i.e. message contents, message size, or data transfer times). The model also does not 
attempt to define actual task durations and instead allows CORE to assign a random task 
length (based on normal distribution) for each task. Again this was intentional as 
otherwise the model could be used to determine actual operational Capabilities and 
Limitations of Navy Command and Control. 

2. Limitations due to Discrete Event Simulation Technique 

The CORE model simulation engine is a discrete event simulation process. 
Because of this, attempts to model a continuous process may not seem to be realistic in a 
sense that the modeler has to break up the continuous process in to a series of discrete 
events. The function Provide Situational Awareness (for example) may not appear very 
realistic to the reader because in reality this is a function that is performed continuously 
through the C2 execution cycles. However, the main purpose of this model is achieved 
even with this limitation. 

3. Physical Resources Limitations Were Not Considered 

The CORE model simulation engine provides the ability for the modeler to 
establish physical resource limitations on the functional model to determine if there are 
adverse affects on mission performance due to resource limitations. The CORE model 
did not attempt to consider these factors as the physical architecture is to be modeled with 
a separate modeling toolset more suited to demonstrating affects due to communications 
and networking architectures. 

E, OPERATIONAL SCENARIO - TRADITIONAL C2 APPROACH 
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The basic structure of the functional model for the traditional C2 approach is 
illustrated Figure 15. The Sequence of function is described below. 



Figure 15 - Traditional C2 Model Overview 


Function 1 (Perform Operations/Tactical Planning) and Function 2 (Provide AOR 
Overwatch) exist in the model to provide initial data inputs and to initiate the Command 
and Control cycle at the CJTF (Function 3: Perform CJTF Art of the C2). Function 3 
models the fundamental activities of Command and Control at the CJTF node. Figure 16 
shows how the follow functions flow: 

a. Maintain alignment 

b. Provide Situational awareness 

c. Advance the plan 

d. Comply with Procedure 

e. Counter the Enemy 


45 









































f. Adjust Apportionment 

The reader should refer to Appendix F for larger seale diagrams illustrating the funetional 
flow. 


DomainSet 001 



Figure 16 - Typical C2 Cycle 

Once initiated the Command and Control cycle at the CJTF activates the JFMCC 
Command and Control Function (Function 4; Perform MOC Art of C2). Function 4 is an 
iterative cycle that is almost identical to the cycle described previously. Once the MOC 
Command and Control function is active, it will activate the Command and Control cycle 
at each CTF (functions 5, 6, and 7). Each of these are iterative cycles that are almost 
identical to the cycle described previously. Each Art of the C2 cycle repeats 50 times 
before terminating. Additionally, once every cycle is complete, the simulation is 
complete and the total simulation time to complete the simulation is recorded for further 
analysis. 

The reader should refer to Appendix E for larger scale diagrams illustrating the 
functional flow. Appendix E also provides more detailed definition of the functions 
performed by the CORE simulation model. 


F. OPERATIONAL SCENARIO-DATA CLEARING HOUSE C2 

APPROACH 


The basic structure of the functional model for the clearing house approach is 
illustrated Figure 17. The Sequence of function is described below. 


ffbd Perform FBM Functions "J 
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Figure 17 - Traditional C2 Model Overview 

Function 1 (Perform Operations/Tactical Planning) and Function 2 (Provide AOR 
Overwatch) exist in the model to provide initial data inputs and to initiate the Command 
and Control cycle at the CJTF (Function 3: Perform CJTF Art of the C2). Function 3 
models the fundamental activities of Command and Control at the CJTF node. 

Unlike the traditional C2 model, all C2 functions at various operational nodes 
synchronize simultaneously with the clearing house. The in effect allows all the 
functional activity to be performed in parallel with every C2 cycle. Figure 18 illustrates 
how the C2 functions in the clearing house approach are modeled. 



Figure 18 - C2 Cycles with Clearing House Approach 

a. Each parallel cycle repeats 50 times before terminating 

b. Once cycles are complete, the simulation is complete and the total simulation 
time to complete the simulation is recorded for further analysis. Appendix D 
provides more detailed definition of the functions performed by the CORE 
simulation model. 

The reader should refer to Appendix E for larger scale diagrams illustrating the functional 
flow. 

G. ANALYSIS OF FUNCTIONAL MODEL DATA 

Once the FFBDs were developed, the COREsim feature was used to simulate the 
timing and interactions of these functions. Through a series of such simulations, results 
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obtained demonstrated revealed how ehanges to the operational architeeture may affeet 
the commander’s ability to perform Command and Control 

a. The Analysis Process Steps 

An overview of the simulation and analysis Process is summarized in the table 
below. Appendix D contains the collected data and statistics calculations. 


Table 14 - Simulation and Analysis Steps 


Step 

Activity 

Objective 

1 

Run Simulation with CJTF 

Functions (no triggers) 

Determine baseline time allocation to 

complete functions at CJTF 

2 

Repeat simulation with data 

synchronization (triggers) 

Time C2 Cycles including staff 

interactions at the CJTF 

3 

Perform T-test of data samples 

from Steps 1 and 2 

Ensure that any differences in data is 

statistically significant 

4 

Run Simulation with CJTF and 

JFMCC functions working in 

parallel 

Determine baseline time allocation to 

complete functions at CJTF and 

JFMCC 

5 

Repeat simulation with data 

synchronization (triggers) 

Time C2 Cycles including staff 

interactions (within JFMCC and 

CJTF and between both commands) 

6 

Run Simulation with CJTF, 

JFMCC, and CTF One functions 

working in parallel 

Determine baseline time allocation to 

complete functions at CJTF, JFMCC, 

and CTF One 
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Step 

Activity 

Objective 

7 

Repeat simulation with data 

synchronization (triggers) 

Time C2 Cycles including staff 

interactions (within JEMCC, CJTE, 

CTE One and between all three 

commands) 

8 

Run Simulation with CJTF, 

JFMCC, CTF One, and CTF Two 

functions working in parallel 

Determine baseline time allocation to 

complete functions at CJTE, JEMCC, 

CTE One, and CTE Two 

9 

Repeat simulation with data 

synchronization (triggers) 

Time C2 Cycles including staff 

interactions (within JEMCC, CJTE, 

CTE One, CTE Two and between all 

four commands) 

10 

Run Simulation with CJTF, 

JFMCC, CTF One, CTF Two, 

and CTF Three functions working 

in parallel 

Determine baseline time allocation to 

complete functions at CJTE, JEMCC, 

CTE One, CTE Two, and CTE Three 

11 

Repeat simulation with data 

synchronization (triggers) 

Time C2 Cycles including staff 

interactions (within JEMCC, CJTE, 

CTE One, CTE Two, CTE Three and 

between all five commands) 

12 

Examine how functions are 

potentially delayed with depth of 

command 

Determine sensitivity of Command 

and Control performance to vertical 

levels of command 

13 

Examine how functions are 

potentially delayed with breadth 

of command 

Determine sensitivity of Command 

and Control performance to 

horizontal levels of command 
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Step 

Activity 

Objective 

14 

Note: CJTF Functions using the 

Clearing House approach is 

functionally equivalent to 

analysis step 1 


15 

Note: simulation with data 

synchronization (triggers) for 

CJTF using the Clearing House 

approach is functionally 

equivalent to analysis step 2 


16 

Run Simulation with CJTF and 

JFMCC functions working in 

parallel using the Clearing House 

approach 

Determine baseline time allocation to 

complete functions at CJT using the 

Clearing House approach F and 

JFMCC 

17 

Repeat simulation with data 

synchronization (triggers) using 

the Clearing House approach 

Time C2 Cycles including staff 

interactions (within JFMCC and 

CJTF and between both commands) 

using the Clearing House approach 

18 

Run Simulation with CJTF, 

JFMCC, and CTF One functions 

working in parallel using the 

Clearing House approach 

Determine baseline time allocation to 

complete functions at CJTF, JFMCC, 

and CTF One using the Clearing 

House approach 

19 

Repeat simulation with data 

synchronization (triggers) using 

the Clearing House approach 

Time C2 Cycles including staff 

interactions (within JFMCC, CJTF, 

CTF One and between all three 

commands) using the Clearing House 

approach 
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Step 

Activity 

Objective 

20 

Run Simulation with CJTF, 

JFMCC, CTF One, and CTF Two 

functions working in parallel 

using the Clearing House 

approach 

Determine baseline time allocation to 

complete functions at CJTF, JFMCC, 

CTF One, and CTF Two using the 

Clearing House approach 

21 

Repeat simulation with data 

synchronization (triggers) using 

the Clearing House approach 

Time C2 Cycles including staff 

interactions (within JFMCC, CJTF, 

CTF One, CTF Two and between all 

four commands) using the Clearing 

House approach 

22 

Run Simulation with CJTF, 

JFMCC, CTF One, CTF Two, 

and CTF Three functions working 

in parallel using the Clearing 

House approach 

Determine baseline time allocation to 

complete functions at CJTF, JFMCC, 

CTF One, CTF Two, and CTF Three 

using the Clearing House approach 

23 

Repeat simulation with data 

synchronization (triggers) using 

the Clearing House approach 

Time C2 Cycles including staff 

interactions (within JFMCC, CJTF, 

CTF One, CTF Two, CTF Three and 

between all five commands) using the 

Clearing House approach 

24 

Examine how functions are 

affected by the number 

operational nodes using the 

Clearing House approach 

Determine sensitivity to number of 

nodes 


H. ECHELON DEPTH OF COMMAND ON TRADITIONAL C2 MODEL 

Table 15 summarizes the results of a series of simulations to demonstrate how the 
ability of eommand and eontrol is affected as the command organization grows vertical 


51 




through several levels of eommand. The simulation scenario was designed to create a 
situation whereby command staff is required to wait on data from their associate staff 
members and command staffs between levels of command. Time and delays are 
expressed in a dimensionless time unit from COREsim. 


Table 15 - C2 Functions Performance (Depth of Command) 


Architecture 

Simulated 

Average Time 
to Complete 
Task 

Average Time to 

Complete Tasks With 
Wait Periods 

Average 

Delay 

CJTF 

7775.94 

7856.19 

80.25 

CJTF +JFMCC 

7790.36 

11854.29 

4063.93 

CJTF+JFMCC+CTFl 

7800.50 

16410.25 

8609.75 


Figure 19 illustrates the average time to complete the C2 cycles and the average 
delay created waiting for data to be passed back and forth within an operational node or 
up and down between echelons of command. Time and delays are expressed in a 
dimensionless time unit from COREsim. 
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Figure 19 - C2 Functions Performance (Depth of Command) 


I. ECHELON BREADTH OF COMMAND ON TRADITIONAL C2 MODEL 

Table 16 summarizes the results of a series of simulations to demonstrate how the 
ability of eommand and control is affected as the command organization grows 
horizontally through several levels of command. The simulation scenario was designed to 
create a situation whereby command staff is required to wait on data from their associate 
staff me members and command staffs between levels of command. Time and delays are 
expressed in a dimensionless time unit from COREsim. 


Table 16 - Impact on C2 of Increased Command Organization 


Architecture Simulated 

Avg. Time to 

Complete 

Task 

Avg. Time to 

Complete Tasks With 

Wait Periods 

Avg. 

Delay 

CJTF +JFMCC + CTF One 

7850.50 

16410.25 

8609.75 

CJTF +JFMCC + CTF One + CTF 

Two 

7865.90 

16536.54 

8670.64 

CJTF +JFMCC + CTF One + CTF 

Three 

7871.14 

16605.63 

8734.49 


Figure 20 illustrates the average time to complete the C2 cycles and the average 
delay created waiting for data to be passed back and forth within an operational node or 
up and down between echelons of command. Time and delays are expressed in a 
dimensionless time unit from COREsim. 
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Figure 20 - C2 Functions Performance (Breadth of Command) 


J. SENSITIVITY ANALYSIS 

Figure 21 provides a snapshot of the summary data of several series of 
simulations. The plot illustrates the sensitivity of delays due to growth of the operational 
organization vertieally and growth horizontally. Time and delays are expressed in a 
dimensionless time unit from COREsim. 
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Figure 21 - Summary Data 


K. CLEARING HOUSE C2 PERFORMANCE 

Table 17 summarizes the results of a series of simulations to demonstrate how the 
ability of command and control is affected when a clearing house approach is utilized. 
The simulation scenario was designed to create a situation whereby command staff is 
required to wait on data from their associate staff members and command staffs between 
levels of command. Time and delays are expressed in a dimensionless time unit from 
COREsim. 


Table 17 - Summary of Functional Model Results 


Architecture 

Simulated 

Average Time 

to Complete 

Task 

Average Time to 

Complete Tasks With 

Wait Periods 

Average 

Delay 

CJTF 

7775.94 

7856.19 

80.25 
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CJTF +JFMCC 

8082.5 

13420.11 

5337.61 

CJTF +JFMCC + CTF 

One 

8202.11 

15954.82 

7752.71 

CJTF +JFMCC + CTF 

One + CTF Two 

8275.73 

16150.14 

7874.41 

CJTF +JFMCC + CTF 

One + CTF Two + 

CTF Three 

8331.25 

16188.14 

7856.89 


Figure 22 illustrates the average time to complete the C2 cycles and the average 
delay created waiting for data to be passed back and forth in the clearing house approach. 
Time and delays are expressed in a dimensionless time unit from COREsim. 
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Figure 22 - Avg. Time & Delay to Complete C2 Cycle 
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L, COMPARING TRADITIONAL AND CLEARING HOUSE C2 
PERFORMANCE 

Based on the simulation data, the performance of the traditional C2 structure is 
compared to the clearing house approach. Figure 23 illustrates how Average Time to 
complete the C2 cycles compares between the traditional and clearing house approaches. 
Figure 24 illustrates how Average Delay incurred during the C2 cycles compares between 
the traditional and clearing house approaches. 
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Figure 23 - Comparing Avg, Time to Complete C2 Cycke 
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Figure 24 - Comparing Avg, Delay to Complete C2 Cycle 


M, OTHER OBSERVATIONS 

One of the observations the project team made during development of the functional 
models was that each of the cycles tends to run at separate rates. Figure 25 shows a 
capture of CORE simulator. Each rectangle represents execution of a function. The top 
six rows represent the conclusion of functions belonging to the CJTF. The remainder of 
the functions belongs to the JFMCC. In this example the JMFCC cycles completed prior 
to the CJTF cycles. The reader should refer to Appendix F larger scale diagrams 
illustrating the functional flow. 
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Figure 25 - CORESUM Results 

The model purposely synchronized all the cycles to the same battle rhythm by 
using data triggers in the model. This created delay in the execution of the cycles as 
functions were created in order to wait for input from other cycles. This highlights an 
interesting aspect of vertical C2 structure that merits more study. According to Vice 
Admiral Willard; 

“The commander's level of knowledge is the basis for control actions. If 
he lacks knowledge in any area, his control actions in that area become 
suspect. Keeping up with the operation in all six areas can be extremely 
challenging depending on the complexity of the plan. Consider the 
dynamics involved; the only area that is relatively static is "maintain 
alignment," because the mission statement and commander's intent should 
be relatively fixed frames of reference. In contrast, situational awareness, 
plan execution, procedures, enemy actions, and apportionment are 
exceedingly dynamic. 
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Now imagine the challenge in keeping up with multiple plans 
being executed concurrently. In naval operations, it is possible that plans 
for air defense, surface defense, undersea warfare, strike, information 
operations, special operations, and amphibious operations all will be 
executed at the same time. Commanders must organize their command 
centers to be able to handle oversight of multiple warfare area plans at 
once or to prioritize the plans and exert control over the most critical 
ones.’’(Willard 2002) 

While VADM Willard spoke of the managing complexity and dynamics, an interesting 
finding of this functional model is that the commander may need to ensure that all of the 
cycles remain synchronized (up and down the echelon of command). Otherwise, the 
commander can find himself out of synchronization with the more tactical cycles. 
Alternatively, if the commander requires speed of execution in the more tactical cycles, 
he may be extremely challenges to keep all forces synchronized. 



N. FUNCTIONAL ANALYSIS FINDINGS 
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The CORE model provided several insights for the projeet team to show how 
Command and Control and Fleet Battle Management are affeeted by organizational 
structure. Additionally, the model provided significant evidence that a materiel solution 
alone may not meet the need to achieve DCNO vision for information dominance. 

1, Traditional C2 Performance 

Based on the simulation results, the traditional C2 structure appears to perform as 
well or better than the clearing house approach. However, it’s noted that performance of 
the traditional C2 organization shows marked delays as the layers of vertical organization 
grows in depth. A key consideration is to keep the C2 organization as flat as possible. 

2, Clearing House Approach 

Based on the simulation results, the clearing house C2 structure appears to 
perform well for large organization (showing less sensitivity to growth than the 
traditional C2 Model). A key consideration is that continued research into a clearing 
house approach may show benefit. 

3, Cycle Synchronization 

A very interesting by product of the project team’s effort was discovery of the 
phenomena of Command and Control cycles proceeding at different rates in a traditional 
C2 organization. This has two implications to the commander; 

• If decisions that need to be made are time sensitive, the operational 
commander may not have the most current information. A key consideration 
is the need to push tactical command as close the tactical edge as possible. 

• For complex operations that require synchronized command at several levels 
of command echelon, the commander may need to sacrifice responsiveness 
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for the synchronization. A key consideration is the balance of speed and 
ability to synchronize command 

4, Clearing House Approach 

The model finding did not show a distinct advantage to the clearing house 
approach. However this may have been a result of applying classic C2 fundamentals 
(based on classic business and communications structures) to a newer information 
paradigm. Before a final conclusion is reached, it is worth investigating newer concepts 
for C2 organization and fleet battle management approach that takes full advantage of 
this new paradigm. 
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VI. DYNAMIC ANALYSIS 


A. MODELING APPROACH 

The design of the experiment was based at the eomponent level of the existing 
network architeeture where different eomponents or eharacteristics of that eomponent 
were altered, so as to see if any performanee differenees ean be observed from those 
ehanges. Changes in real life environments are typieally made through hardware ehanges 
sueh as the replaeement of hardware, altering eomponent eharaeteristies, or even altering 
the network arehiteeture. By applying the seientifie method, where one independent 
variable is ehanged, observations can be made to see the effect of that variable. 
Complexities can occur when variables have unforeseen dependencies on others, but for 
this experimentation purpose, simple parametric changes will be concluded as being 
independent in nature. The baseline system is represented within the OPNET model as 
the “As-Is” architecture. Changes are made, a simulated run is created and data then 
collected. Observations from the experiment are summarized and through the use of 
statistical analysis, differences from the baseline architecture can be noted and 
determined if that component change can create a significant change to the existing 
network. 

B, BASELINE DESCRIPTION 

The notional baseline OPNET model was created as an abstract representation of 
a theatre network. The attempt of the baseline model was to represent the network 
architecture of current command and control implementation. The model consists of the 
following operational nodes: 

• Commander Joint Task Eorce (CJTF) 

• Joint Eorce Maritime Combat Commander (JEMCC) 

• Command Task Forces (1, 2, 3) (CTFl, CTF2, CTF3) 

Each of the nodes had clients and servers passing database application traffic over 
a network consisting of routers and SATEEEITE COMMETNICATIONS terminals. Basic 
network topology consisted of single Cisco 4000 series router and a SATEEEITE 
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COMMUNICATIONS link with a total capacity of 1024 Kbps. All Scenarios used a 
WSC-6 (V-5) satellite terminal. The JFMCC uses a 7505 router to handle ineoming 
traffic load. The JFMCC eonnects to a land based CTF ashore node through an optieal 
land network. 



Figure 27 - Operational View 

Command and eontrol data traffic was represented using an applieation demand 
profde from JCSS. A speeific database demand profde was deployed aeross the 
operational nodes to simulate the command and control traffic flow. As illustrated in 
Figure 28, database query response time is the time elapsed between sending a request 
and receiving the response packet. Measured from the time when the Database Query 
Application sends a request to the server and to the time that response paeket is reeeived. 
Every response packet sent from a server to the Database Query Application is included 
in the statistic. Comparing this value with traffie flow, along with other key values can 
give a eolleetive evaluation of network performance. 
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C. LIMITATIONS OF THE MODEL 

To ensure that readers properly understand limitations of the structural model the 
assumptions and limitations are listed below. 

a. Actual shipboard network architecture was not modeled. Instead, an abstraction 
of typical shipboard network architecture was implemented for modeling 
simplicity and consistency across excursions. 

b. Processing and behavior of the C2 systems were not characterized. 

Representative data flows were used rather than actual data flows. If 
representative data flows were used, model classification would not remain 
unclassified. 
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c. A notional operational construct was assumed. A specific communication plan or 
Operational Plan was not selected. The chosen operational construct was used for 
simplicity of modeling. 

d. Available presets were used from the OPNET model for application demands. C2 
traffic was modeled as an application demand using a “high” traffic demand. 

e. Simulation period was fixed at 15 minutes in order to capture a statistically 
significant number of model runs. 

f. Disconnected/ intermittent communications were not modeled. All excursions 
assumed fully connected communication between operational nodes. 

g. Multiple satellite communications paths were not modeled. All excursions 
assumed a single Super High Frequency satellite communications link between 
operational nodes. 

h. Not all possible Information Exchange Requirements (lERs) were modeled such 
as Plain Old Telephone System and Voice Over IP. 

i. For the experiment, email passing through the TCP layer was chosen to be a 
representative choice for simulation message exchanges from one command to 
another. Transfer times of the packet from point to point is collected indicating 
the current performance of the network. Understandably, there are many factors to 
consider, but simplicity and seeing fundamental differences became a desirable 
direction. 


D, MODELING SCENARIOS 

1. Alt_l_RouterUpgrade 

In this scenario, each of the CTF operational node routers were upgraded from a 
Cisco 4000 model series to a Cisco 7000 model series. The presumption was these 7000 
series routers support 2 Gbps bandwidth. 
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Each of the numbered CTFs were netted together to form a mesh network. The 
CTFs each contained an Ethernet server that represented the task foree eommand and 
control server. Client-server exchanges between an Ethernet elient workstation and 
command and control servers on other CTF platforms ensured that all platforms 
maintained an accurate COP. A detailed explanation of the network topology for this 
scenario can be found in Appendix G. Command and control data exchanges were 
created using an exponential distribution with an interarrival time of twelve seconds and 
a fixed transaetion size of 32768 bytes. The output for each of the simulation runs is 
shown below in Table 20. The mean database query time for the five-run set was 2.26 
seconds. 


Table 20 - Alt 1, Upgraded Routers Results 



Mean 

Min 

Max 

StdDev 

Varianee 

1 

3.164327 

2.115768 

5.03182889 

0.443066 

0.196307 

2 

2.143537 

0.062575 

4.98445366 

1.473899 

2.172379 

3 

2.190082 

0.064039 

5.70666699 

1.509812 

2.279532 

4 

0.06437 

0.062575 

0.09789252 

0.003263 

1.06E-05 

5 

3.738317 

2.097397 

7.94913235 

1.105585 

1.222317 
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2, Alt_2_Satellite_Capacity 

In this scenario, satellite links between operational nodes were increased from a 
bandwidth of 1544 KBps to 2048 KBps. The presumption with this scenario is inereased 
eapacity on eaeh link would allow for higher data throughput for operational nodes. 



The network topology was the same as the current arehiteeture, but with 
additional satellite capaeity on each of the links. A detailed explanation of the network 
topology for this scenario ean be found in Appendix G. Command and eontrol data 
exchanges were created using an exponential distribution with an interarrival time of 
twelve seeonds and a fixed transaction size of 32768 bytes. The output for each of the 
simulation runs is shown below in Table 21. The mean database query time for the five- 
run set was 5.75 seeonds. 


Table 18 - Alt, 2, Satellite Capacity Results 



Mean 

Min 

Max 

StdDev 

Varianee 

1 

7.143924 

2.125386 

47.42647 

8.42142 

70.92031 
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2 

7.918981 

2.132946 

63.63215 

9.640234 

92.93411 

3 

7.266971 

0.0626 

40.89453 

9.294441 

86.38664 

4 

5.143012 

0.0626 

39.06716 

8.088966 

65.43137 

5 

1.291543 

0.063633 

5.640359 

1.673626 

2.801024 


3, Alt_3_Router_Satellite_Upgrade (Dedicated combat Router and 

satellite capacity) 

In this scenario, C2 traffic was passed over a dedicated combat router between 
each of the operational nodes. Lower priority traffic was passed through a separate router. 
Additionally, satellite capacity was increased from 1544 Kbps to 2048 Kbps. 



Figure 31 - Alternative 3, Router & Satellite Upgrade 

The network topology in this seenario has the upgraded satellite links similar to 
alternative two. However, a client Ethernet workstation and SATCOM link was created 
for the non-combat traffic. A detailed explanation of the network topology for this 
scenario can be found in Appendix G. C2 data exchanges were created using an 
exponential distribution with an inter-arrival time of twelve seconds and a fixed 
transaction size of 32768 bytes. The output for each of the simulation runs is shown 
below in Table 19. The mean database query time for the five-run set was 2.11 seconds. 
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Table 19 - Alt, 3, Router & Satellite Upgrade Results 



Mean 

Min 

Max 

StdDev 

Variance 

1 

2.277514792 

0.070528 

6.271971 

1.652699 

2.731413 

2 

0.968511105 

0.070528 

5.26305 

1.340509 

1.796965 

3 

2.117848808 

0.070528 

7.345731 

1.657506 

2.747327 

4 

3.290351355 

2.357018 

5.961603 

0.674542 

0.455007 

5 

1.937671686 

0.070528 

6.078935 

1.445602 

2.089765 


4, Alt_4_DiffServ (DiffServ) 

In this scenario, C2 traffic was routed using a priority queuing QoS scheme. A 
DSCP based QoS profile was used for packet traffic. C2 traffic packets were marked for 
expedited forwarding at router interfaces. A detailed explanation of the network topology 
for this scenario can be found in Appendix G. The output for each of the five simulation 
runs is shown below in Table 20. The mean database query time for the five-run set was 
2.61 seconds. 


Table 20 - Alt, 4, DiffServ Results 



Mean 

Min 

Max 

StdDev 

Variance 

1 

3.19412994 

2.103107 

5.954862 

0.597023 

0.356437 

2 

2.356829368 

0.0626 

7.438029 

1.508999 

2.277079 

3 

2.204247338 

0.0626 

8.200867 

1.580166 

2.496925 

4 

3.150453815 

2.092171 

5.943398 

0.590629 

0.348843 

5 

2.150902867 

0.0626 

6.403549 

1.711013 

2.927564 


5, Alt_5_Dedicated Router (Dedicated Combat routers) 

Each CTF node has a basic network topology as described in the current 
architecture description. However, there is an auxiliary network with a Cisco 4050 router 
and a client workstation to send C2 data between each respective CTF. 
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Figure 32 - Alternative 5, Dedicated Routers 


Network topology modifications for this scenario included segregating all combat 
and non-combat traffic. A client Ethernet workstation, router and dedicated SATCOM 
connection were deployed to segregate the two traffic types. A detailed explanation of the 
network topology for this scenario can be found in Appendix G. Command and control 
data exchanges were created using an exponential distribution with an inter-arrival time 
of twelve seconds and a fixed transaction size of 32768 bytes. The output for the 
simulation runs is shown below in Table 21. The mean database query time for the five- 
run set was 1.96 seconds. 


Table 21 - Alt, 5, Dedicated Router Results 



Mean 

Min 

Max 

StdDev 

Variance 

1 

2.834375 

0.070528 

9.721016 

2.280378 

5.200123 

2 

1.477662 

0.070528 

8.252114 

2.219676 

4.92696 

3 

2.013631 

0.070528 

6.486076 

1.58506 

2.512417 

4 

1.560763 

0.070528 

10.1299 

2.3267 

5.413533 

5 

1.92786 

0.070528 

6.20473 

1.626158 

2.64439 


6, Alt_6_PriorityQueued 

The purpose of this excursion is to examine priority queuing techniques under a 
stressed SATCOM link. The network topology for this scenario is the same as 
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Alt_4_Difffierv. However, in order to ereate a stressed SATCOM link, information 
exehange requirements were deployed on eaeh of the SATCOM links in the mesh 
network. A DSCP based QoS profile was used for eommand and eontrol traffie. C2 
traffie paekets were marked for expedited forwarding at router interfaees. Command and 
eontrol data exehanges were ereated using an exponential distribution with an interarrival 
time of twelve seeonds and a fixed transaetion size of 32768 bytes. The output for eaeh of 
the simulation runs is shown below in Table 22. The mean database query time for the 
five-run set was 2.76 seeonds. 


Table 22 - Alt. 6, Priority Queued Results 



Mean 

Min 

Max 

StdDev 

Variance 

1 

2.559644138 

0.070528 

8.22809 

1.994492 

3.977997 

2 

3.781552902 

2.111873 

9.523247 

1.258133 

1.582899 

3 

1.758739734 

0.070528 

9.934209 

2.387784 

5.701513 

4 

2.190668157 

0.070528 

4.892946 

1.480061 

2.190581 

5 

3.531753607 

0.070528 

10.83491 

2.674309 

7.151928 


E, DYNAMIC ANALYSIS FINDINGS 

Figure 33 is a least-squares trend line used to summarize the database query 
response times. The following observations are made for the eomparisons of eaeh model. 

1. Dedicate Routers 

The arehiteetures modeled did not deseriminate any option based on performanee. 
From Figure 33, the shortest response time was alternative five, dedieated eombat router 
seenario. Of the alterntives modeled, this alternative provided the best alternative to 
reduee eommand and eontrol information delay. All of network teehnologies modeled 
provided suitable performanee. 

2, Performance over Time 

The seenario used the model alternatives with purposely loaded eommunieation 
and network resourees in order to surfaee the performanee eharaeteristies. Sinee the 
projeet team strategy was not to attempt to ereate a model of real word terrestrial, 
satellite, or shipboard networks (due to data elassifieation eoneerns with illustrating fleet 
eapabilities and limitations) the reader may want to take eare in drawing eonelusions 
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concerning actual fleet network fleet performanee. However, the model does prediet that 
if the networks are loaded to capacity and the satellite eommunication eapaeity remains 
fixed, the C2 delays and overall quality will diminish with time (ineluded eurrent 
systems). Therefore the operational eommander may need to balanee the requirements for 
information with stability of C2 networks. 

3. Satellite Comminication Capacity. 

Unexpeetedly, inereasing satellite data eapaeity did not provide shorter database 
query response time (in the short term). It is possible that with more time overall 
performanee may have stabilized to a favorable outcome. The safest eonelusion to reach 
is that increasing satellite capacity can easily improve data throughput but may not in 
itself reduce delay time. Given a longer simulation runtime, Alt_2_Satellite_Capacity 
may provide shorter database query response times. 
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Figure 33 - DB Query Trend Lines 


F. CLEARING HOUSE 

The clearing house architecture is based on having a centralized data center to 
handle information exchange quickly and easily through direct data transfers. The JCCS 
model depicts a single operational facility in which all CTFs and JFMCC obtain 
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information theoretically through a single information request and data exchange. The 
central focus of the clearing house is to collect and disseminate data request as soon as 
data is available so as to ensure all participants have current synchronized information. 



The JCCS model is the adaption of the baseline architecture containing equivalent 
system hardware using similar systems and capabilities as identified within the baseline 
system. Cisco 4050 routers were used within the CTFs and Cisco 7000 routers for the 
JFMCC. Satellite bandwidth was kept at 1544 Kbps. Simulation runs were executed 15 
minutes with identical seed values. 

A simulation run is composed of a model running for 5 runs each with a period of 
15mins using a predefined set of seed values for each run. The same seed list is used for 
each modeling change as specified by the Discrete Event Simulation (DES) list. The 
seed essentially provides randomness for generating data flow injected into the network 
so as to reflect real-time use. Eor example, a seed value of 0 would provide a constant 
injection rate of data into the network. The time of 15mins was chosen since longer times 
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generated a tremendous amount of data points whieh stabilized just shortly before the 
15min time interval. As for the types of data that was eolleeted, Appendix G indieates 
whieh data items were seleeted for eolleetion in OPNET. Figure 35 illustrates the trend 
lines generated from the simulation for each DBS value. 



1. Limitations of the model 
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To ensure that readers properly understand limitations of the clearing house 
model, assumptions and limitations are listed below. 

a. Actual shipboard network architecture was not modeled. Instead, an 
abstraction of typical shipboard network architecture was implemented for 
modeling simplicity and consistency across excursions. 

b. Processing and behavior of the C2 systems were not characterized. 
Representative data flows were used rather than actual data flows. If 
representative data flows were used, model classification would not 
remain unclassified. 

c. A notional operational construct was assumed. A specific communication 
plan or Operational Plan was not selected. The chosen operational 
construct was used for simplicity of modeling. 

d. Available presets were used from the OPNET model for application 
demands. C2 traffic was modeled as an application demand using a “high” 
traffic demand. 

e. Simulation period was fixed at 15 minutes in order to capture a 
statistically significant number of model runs. 

f. Disconnected/ intermittent communications were not modeled. All 
excursions assumed fully connected communication between operational 
nodes. 

g. Multiple satellite communications paths were not modeled. All excursions 
assumed a single Super High Frequency satellite communications link 
between operational nodes. 

h. Not all possible Information Exchange Requirements (lERs) were 
modeled such as Plain Old Telephone System and Voice Over IP. 

i. For the experiment, email passing through the TCP layer was chosen to be 
a representative choice for simulation message exchanges from one 
command to another. Transfer times of the packet from point to point is 
collected indicating the current performance of the network. 
Understandably, there are many factors to consider, but simplicity and 
seeing fundamental differences became a desirable direction. 
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1, Basic Clearing House Analysis 

The trend line from eaeh seed shows they eonverge at a 3 seeond response time that is 
slightly higher than the other alternatives. A statistical summary is provided in Table 23. 
Overall, evaluating the means indicate that there was no significant performance 
difference than the other scenarios. 


Table 23 - Clearing House 


Mean 

Min 

Max 

StdDev 

Variance 

3.165585297 

0.070528 

8.22809 

1.994492 

3.977997 

2.231610802 

2.111873 

9.523247 

1.258133 

1.582899 

2.148046519 

0.070528 

9.934209 

2.387784 

5.701513 

3.580180508 

0.070528 

4.892946 

1.480061 

2.190581 

2.574173672 

0.070528 

10.83491 

2.674309 

7.151928 


Evaluating the top three trend lines of the alternate scenarios including the 
baseline with the clearing house, shows their comparisons in Figure 36 using a DES-3 
result. The selection of DES-3 was arbitrary with comparisons using different seed values 
showing similar characteristics. 
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2, Clearing House Findings 

The following observations are made for the comparisons of each model. 

• With a clearing house approach, more traffic is expected to pass through a 
central point, which may attribute to a longer response time. 

• A single router, a Cisco 7505, at the clearing house is handling all traffic. 
Having a dedicated router for each satellite was shown to be effective. 

• Satellite capacity of 1544 Kpbs used for the traditional C2 architecture 
was also used for the clearing house model. Presumably additional 
satellite capacity may improve the outcome 

Recommendations from the observations by the alternatives indicate that using 
dedicated routers to handle the extra traffic is necessary. A server cluster or server farm 
would provide the needed requirements to handle the expanded data flow. Router 
upgrades as well as increasing satellite bandwidth would improve traffic performance as 
well. 
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VII. DESCISION ANALYSIS 


A. METHODOLOGY EMPLOYED 


The project team employed a quantitative decision matrix to establish priorities of 
several possible systems of system approaches for evaluated various alternatives based on 
modeling and simulation results to determine a score of benefit to fleet battle 
management based on the weighted value system developed in the Research Phase. 
Figure 31 illustrates this process 


Determine Suitable 
Alternatives 


Value System 









Estimate 

Performance using 
Modeling & 
Simulation 







O 



V 

y 



Score the 

0 

Adjust Score for 

0 

Report 

Results 

Performance of 
Each Alternative 

Value System 
Weights 


Figure 37 - Summary of Decision Analysis Process 


B, METHODOLOGY EMPLOYED 


Modeling and Simulation was employed by the project team to help predict 
performance system of systems alternatives. In many cases the determination of the 
performance required extrapolation of the modeling and simulation results since not 
every permutation possibility was modeled. In addition the models purposely did not try 
to simulate real world performance to avoid any issues with data classification of the 
results and findings. 
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The project team employed a comparative analysis technique in order to overcome 
the problem of not being able to score alternatives based on actual expected performance. 
Initial step was model the as-is network and communication systems to determine the 
baseline performance. Significant excursions from the baseline (router improvements 
satellite communications improvements, etc) were modeled to determine the relative 
effect. The project team made several assumptions to permit interpolation of the 
modeling results to form this ranking. 

• Satellite communication upgrades were additive to the overall performance of 
and networking and router upgrades. 

• Multi-Protocol Label Switch (MPLS) technology was not explicitly modeled. 
It was assumed (for command and control traffic) that MPLS will perform 
similarly as a dedicated system of routers 

• Details of routing systems in the DISN cloud were not considered in the 
modeling nor the scores 

• JCSS had readymade modeling tools for CISCO System hardware, however 
the project team assumed that similar performance would be obtained using 
other vender products. 

Overall this allowed the team to develop a ranking evaluation for the various 
alternatives against the user’s value system. These rankings were used as input into the 
decision matrix that is discussed in the next section. 


C. DECISION MATRIX 

Based on these models, each alternative was ranked as to its ability to satisfy the key 
measure in the user’s value system. The raw score illustrated in the decision matrix in 
Figure 32 is the summation of the ranking multiplied by the weights. For the scoring in 
this matrix, the higher performing alternatives received a higher rank. For example; 
Dedicated routes with standard SATCOM was determined to be the best performing 
option so it is ranked highest with a score of 14. 
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0.21 

0.21 

0.19 

0.19 

0.21 


Baseline (current systems) 

Baseline (current systems) 

10 

10 

10 

10 

10 

10.1 

Baseline (current network 
systems) 

Upgrades 

9 

9 

9 

9 

9 

9.09 

Implement DIFFSERVE 

Standard 

6 

6 

6 

6 

6 

6.06 

Implement DIFFSERVE 

Upgraded 

5 

5 

5 

5 

5 

5.05 

Implement MPES 

Standard 

4 

4 

4 

4 

4 

4.04 

Implement MPES 

Upgraded 

3 

3 

3 

3 

3 

3.03 

Upgrade Routers 

Standard 

8 

8 

8 

8 

8 

8.08 

Upgrade Routers 

Upgraded 

7 

7 

7 

7 

7 

7.07 

Dedicated C2 Routers 

Standard 

14 

14 

14 

14 

14 

14.14 

Dedicated C2 Routers 

Upgraded 

13 

13 

13 

13 

13 

13.13 

Upgraded Routers w/MPES 

Standard 

12 

12 

12 

12 

12 

12.12 

Upgraded Routers w/MPES 

Upgraded 

11 

11 

11 

11 

11 

11.11 

Clearing Flouse 

Standard 

2 

2 

2 

2 

2 

2.02 

Clearing Flouse 

Upgraded 

1 

1 

1 

1 

1 

1.01 


Total Ranking Points 






106.1 


Figure 38 - Decision Matrix 
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For this particular case each alternative was either measured or predieted to 
perform similar with respeet to eaeh of the five measures identified in the value system. 
Therefore the value system weights did not help diseriminate between alternatives. 

D. SUMMARY OF FINDINGS 

Based on the Normalized score derived from the deeision matrix, Table 24 
provides the Benefit Seoring of each alternative (higher is better). These results will be 


used to seore cost versus benefit later in this report. 

Table 24 - Benefit Scoring of Alternatives 


ALTERNATIVE 

Benefit (Normalized) 

NETWORK 

SATCOM 


Baseline (eurrent systems) 

Baseline (current systems) 

0.10 

Baseline (eurrent network systems) 

Upgraded 

0.09 

Implement DiflServ 

Standard 

0.06 

Implement DiflServ 

Upgraded 

0.05 

Implement MPES 

Standard 

0.04 

Implement MPES 

Upgraded 

0.03 

Upgrade Routers 

Standard 

0.08 

Upgrade Routers 

Upgraded 

0.07 

Dedicated C2 Routers 

Standard 

0.13 

Dedieated C2 Routers 

Upgraded 

0.12 

Upgraded Routers w/MPES 

Standard 

0.11 

Upgraded Routers w/MPES 

Upgraded 

0.10 

Clearing House 

Standard 

0.02 

Clearing House 

Standard 

0.01 
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VIII. LIFE CYCLE COST ANALYIS 


A, METHODOLOGY 

Life cycle cost estimation (LCCE) for this capstone project was based on 
representative Navy command and control, network, and satellite communications 
systems. Sixty-nine exhibits from these program’s cost data were studied to create a Cost 
Breakdown Structure (CBS). The CBS was created following the process guidance from 
“Cost Analysis Guidance and Procedures”, DoD 5000.4-M.(Department of Defense 
1992) In addition, the data was used to create a summary cost table for life cycle cost per 
year for ten years. This summary cost estimate is also used to estimate a cost for the 
proposed solution. It then was used to analyze the cost versus expected benefits. 

The life cycle phases of the system were Research & Development (R&D), 
Production & Installation (P&I), and Operations & Support (O&S). No calculations for a 
Retirement & Disposal phase were included as it was assumed that Tech Refresh cycles 
continually remove the antiquated hardware. Figure 33 shows the life cycle phases with 
estimated years for each phase. 




R&D 

P & I 

O&S 







^ ^ 1 1 1 1 1 1 1 

1 23456789 

Years 


Figure 39 - Program Life Cycle Phases 

The cost breakdown structure shown in Figure 40 was developed based on sample 
data Fife Cycle Cost Estimate provided by analogous Navy and Joint Program. 
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Figure 40 - Cost Breakdown Structure 


Research and development cost elements include the following activities: 
program management, acquisition management, financial management, logistics 
management, and contract management. It also includes engineering research and 
development to design hardware and software of the system, perform systems 
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engineering tasks sueh as eonfiguration management, logisties engineering, Automated 
Data Proeessing (ADP) and Teehnieal Direetion Authority (TDA) support. The last 
major portion of this eost eategory is engineering test and evaluation. 

Produetion and Installation eost elements inelude hardware and software 
proeurement and installation, and spare parts. It also ineludes funding for Integrated 
Logistie Support (ILS) teams who perform test and installation and provide system initial 
operation training and equipment familiarity training. This eost element also ineludes 
teehnieal doeumentation providing engineering data, management data, logisties support 
data, and data repositories. 

Finally, the Operation and support eost ineludes the eost of mission personnel, 
operator training, and operational faeilities. In addition, it also ineludes the eost of 
maintenanee personnel, maintenanee training, outfitting and spare parts, software 
maintenanee, help desk tasks and warranty management. Sustaining logisties support was 
estimated based on an estimation of pereentage of equipment going end of life (EOT) 
during the operations phase and the test and installation support needed to replaee the 
EOL equipment. 

As artieulated earlier, there was no eost estimated for disposal phase. However, 
this eost is estimated under external aetivities to SPAWAR funetions. This phase would 
inelude system phase out and disposal eost and remediation eosts. 

B. COST ANALYSIS 

The eosts of the alternative solutions were estimated in order to evaluate the total 
Eife Cyele eosts for eaeh alternative. A summary of these eosts is provided in Table 25. 
Appendix C provides detailed Eife Cyele Cost Estimates for eaeh alternative. The key 
assumptions that the projeet team used in this analysis are: 

• The baseline eost of RDT&E and OPN were derived from historieal data in 
order to ealeulate future years’ eost, however the historieal eosts are 
aeeounted as sunk eost and thus not ineluded in this life eyele eost analysis. 
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• The cost of alternatives cost is spread to multiple years due to assumption by 
the project team that the upgrade will take more than one year to implement 
(which is typical based on deployment schedules and ship availability). 

• A hardware refresh was assumed to happen during the fifth year of life cycle. 

• The costs of alternatives utilizing current SATCOM capacity are close to the 
baseline cost except for the priority queuing alternative. 

• The priority queuing alternative cost noticeably lower than the other 
alternatives by about half the cost. This is due to the reduction in number of 
watch-standers from 4 to 2 personnel required to monitor the system. 

• The Operations and Maintenance (O&M) cost for all other alternatives remain 
same as the baseline as the personal and manning are assumed to be same in 
those cases. 

• The cost of hardware are based on commercial cost per unit and the 
implementation efforts are based on info gathered from team members who 
are subject matter experts 


Table 25 - Summary of Cost for Alternatives 



Current SATCOM 

Capacity 

($k) 

Upgraded SATCOM 

Capacity 

($k) 

Baseline 

8,991,091 

135,355,734 

Upgraded Routers 

9,051,786 

138,495,183 

Implement DiflServ in 

Routers 

8,996,889 

135,361,545 

Implement Multi Protocol 

Label Switching 

9,018,527 

135,374,445 

Dedicated Routers 

9,074,013 

135,362,348 

Upgraded Routers + MPLS 

9,122,325 

138,510,973 

Priority Queues 

5,176,798 

131,594,040 
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Cost $K Cost $K 


Figures 41 and 42 show the costs of alternatives utilizing both current and 
upgraded SATCOM capacities in graphical format. 

9,500,000 
9,000,000 
8,500,000 
8,000,000 
7,500,000 
7,000,000 
6,500,000 
6,000,000 
5,500,000 
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Figure 41 - Cost of Alternatives with Current SATCOM Capacity 
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Routers DiffServ in MPLS Routers Routers + Queues 
Routers MPLS 

Figure 42 - Cost of Alternatives with Upgraded SATCOM Capacity 
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C. COST VERSUS BENEFIT 

For each of the alternatives, the project team considered the cost vs. benefit in 
order to determine if there was any trends or findings that could be use to form 
recommendations for investment strategies. A graph of this is provided in Figure 43. 
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Figure 43 - Benefit vs. Cost 
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This graph shows that that there are several low eost options, with relatively little 
benefit. At the other extreme, there is a eluster of options that provide more benefit with 
great eost. The only option that appears to offer reasonable benefit for the eost is the 
option labeled; Dedieated Router, whieh employs a dedieated set of routers for C2 traffie 
with the existing SATCOM eapability. 


D. COST ANALYSIS FINDINGS 

The LCCE for the alternatives provides good insight to the projeet team for the 
eompletion of the trade-off study. 

1, Routers and Network Upgrades 

The alternatives using router upgrade eost more than the ones with software or 
eonfiguration upgrades. This is due to the higher eost of routers and installation materials. 
Operations and Support eosts remain basieally the same for eaeh alternative, whieh 
logieally keeps the LCCE eomparable aeross these alternatives 

2, Increased Satellite Bandwidth Alternatives 

Alternatives employing inereased satellite eommunieation bandwidth ineur 
inereased system eosts, averaging $127,231,834K per alternative over a ten-year system 
support. The eost of SATCOM upgrade is based on historieal RDT&E and OPN eost of 
implantation of 4 SATCOM terminals. The eost of SATCOM upgrade is estimated to be 
$131,048,789K in today’s dollar value, based on a eonservative 3% average yearly 
esealation. This maybe an unfair eomparison as its reasonable to expeet that no single 
network applianee will remain in fleet use for more than 10 years, but SATCOM eosts 
ean be amortized over longer timeframes. It should be noted that for ease eomparison 
between the various options, the projeet team kept to a ten-year life cyeles for eaeh option 

3, Clearing House May Avoid Costs 

The most ehallenging alternative to provide eost estimates for the elearing house 
as the projeet team was not able to have a detailed design of an aetual elearing house 
installation. However, the large advantage of the elearing house approaeh is the ability to 
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reduce manning requirements for COP data base managers. Because the reductions were 
significant, the Clearing House alternative offers significant cost savings over the same 
ten-year period. 
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IX. RISK ASSESSMENT 


A. METHODOLOGY 

Risk is the potential loss oeeurring when executing one or a series of events. It is 
measured as the combined effect of the probability of occurrence and the assessed 
consequence given that occurrence (Blanchard, p 344). The majority of the risk analysis 
performed is based on the potential of not meeting a specified benchmark. This 
investigation categorizes risk against those benchmarks whether they are technical and or 
programmatic in nature. However, benchmarks are directly linked to the of all system 
risk as not being able support adequate C2 to preclude loss of life and or property of the 
blue force while obtaining the C2 goals and objectives. In order to quantify the potential 
loss or impact it is often necessary to define the both the likelihood and consequence of a 
risk event occurring. The risk analysis methodology adopted and described in this section 
provides the project management team and stakeholders insight to the risks associated 
with each alternative under review. 

To evaluate and compare risks of the alternative solutions a quantitative risk 
assessment process adapted from Systems Engineering Management was utilized by the 
project team. (Blanchard 2008). Each alternative was assessed for cost, schedule, and 
performance impact. 

Traditionally risk analysis in engineering has been to ensure the design is capable 
to conservatively avoid risk. This risk focus is usually defined as some performance 
failure metric and risk is mitigated by applying an engineering safety factor. However as 
systems become more complex and engineering becoming increasingly integrated into 
the overarching development process, risk analysis is required to support additional 
activities involving cost, schedule and even policy decision making. To fully analyze the 
findings detailed within this effort, two types of risk assessments are utilize in supporting 
a decision matrix. Qualitative and quantitative risks are both utilized to adequately 
address the alternative under review. Thus the analysis will characterize the engineering, 
complexity, performance, cost, and schedule risk associated with each of the alternatives 
according to the risk methodology. This methodology adopted is illustrated in Figure 33, 
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Simplified Risk Analysis Methodology Flow Chart. To faeilitate the risk management 
proeess, potential risks are identified and eharacterized in order to determine probability 
of a failure (Pf) oeeurring and the eonsequenee of that failure (Cf). Mathematieally, this 
model ean be expressed as: 

Risk factor (RF) = Pf + Cf - (Pf)(Cf) 

As shown, the overall risk faetor is determined from the union of the two sets, 
noting that RF is largest when both Pf and Cf are large and may be high if either is large. 
To provide greater fidelity, Pf and Cf ean be defined by sub risks and weighted to refieet 
the realities of the solution environment. Table 26, Risk Sub Faetor Assignment and 
Weighting Rubrie, provides the weighting assigned to speeifie sub risk parameters and 
updated mathematieal risk formula. Tables 27, Probability of Failure (Pf) Rubrie and 28, 
Consequenees of Failure (Cf) Rubrie, eontain the sub risk faetors rubrie utilized to 
determine the numerie values of risk analysis. Using the rubrie guides, eaeh sub risk 
faetor is evaluated and assigned a value aeeording to the most appropriate eondition 
refleeted in its respeetive rubrie. After all sub risk faetors are determined, the overall risk 
faetor ean be determined for eaeh potential solution. The overarehing risk factor is 
considered the union of sets which contain the probability of failure and the consequence 
of failure. The probability of failure is derived from the following attributes; maturity 
factor (Pm), complexity factor (Pc) and dependency factor (Pd). The maturity and 
complexity factors are comprised of subunits that characterize the hardware and software 
implementation separately. The consequences of failure are assessed on the impact on the 
following attributes; technical performance (Ct), cost (Cc) and schedule (Cs). 

In order to properly meet the objectives of this potential C2 technology 
enhancement, specific attributes are weighted more than others being considered. In our 
case, the risk of personnel and property being lost is most dependent on the technical 
performance and therefore it is weighted more than cost and schedule. Likewise hardware 
and software failures may not have the same impact depending on the maturity or the 
complexity of the configuration. All weighing assignments as assessed and assigned are 
listed in Table 26, Risk Sub Factor Assignment and Weighting Rubric. 
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RISK ANALYSIS 

IDENTIFY POTENTIAL RISK ITEMS 



Figure 44 - Simplified Risk Analysis Methodology [From Blanchard 2008] 
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Table 26 - Risk Sub Factor Assignment and Weighting Rubric 


RISK 

Pf =(.l*Pmhw) + (. 

Cf=i 

^CTOR (RF) = Pf + Cf- Pf Cf 
l*Pmsw) + (.2*Pchw) + (.3*Pesw) + (.3*Pd) 
t.5*Ct) + (.3*Cc) + (.2*Cs) 

Nomenclature 

Risk Sub Factor 
Description 

Weighting 

Weighting Rationale 

Pmhw 

Probability Factor 
relating to 

hardware maturity 

.1 

Hardware is considered mature 

p 

^ msw 

Probability Faetor 
relating to 

software maturity 

.1 

Software elosely related to routing 
and communieation software is 

mature 

P chw 

Probability Faetor 
relating to 

hardware 
complexity 

.2 

Hardware, although mature, may 
exhibit unknown behavior in 
eomplex networks 

p 

^ csw 

Probability Factor 
relating to 

software 
eonfiguration 
eomplexity 

.3 

Software is eonsidered mature for 
the teehnologies evaluated, 

however eomplex systems various 
software often exhibit less than 
optimum performanee as a result of 
poor eonfiguration optimization 

Pd 

Dependeney 
faetor related to 
existing legacy 

systems 

.3 

Infrastrueture eannot be replaeed in 
whole, therefore all solutions are 
dependent at various degrees on 
legaey systems 

Ct 

Consequenee of 
technieal 
performance 
failure 

.5 

Future performanee inerease is 
paramount due to the rising tempo 
of eonfiicts 

Ce 

Consequenee of 
eost over runs 

.3 

Cost is signifieant, however if 
performanee inerease is signifieant 
with marginal eost inerease, 
additional funds may be obtained 

Cs 

Consequenee of 
sehedule slippage 

.2 

Schedule provides the most trade 
space as existing systems are 
providing a level of acceptable 
performanee near term if 

implementation delay is short 
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Table 27 - Probability of Failure (Pf) Rubric 


Probability of Failure (Pf) 

Magnitude 

Maturity Factor (Pm) 

Complexity Eactor (Pc) 

Dependency 
Eactor (Pd) 

Dependency 
Factor (Pd) 

Software 

(Pmsw) 

Hardware 

(Pchw) 

Software 

(Pcsw) 

0.1 

Low 

Existing 

Existing 

Simple 

design 

Simple 

design 

Independent of 

existing 

system, 

facility or 

associate 

contractor 

0.3 

Minor 

Minor 

redesign 

Minor 

redesign 

Minor 

increases 

in 

complexity 

Minor 
increases in 
complexity 

Schedule 

dependent on 

existing 

system, 

facility or 

associate 

contractor 

0.5 

Moderate 

Major 

change 

feasible 

Major 

change 

feasible 

Moderate 

increase 

Moderate 

increase 

Performance 
dependent on 
existing 
system 
performance, 
facility or 
associate 
contractor 

0.7 

Significant 

Technology 

available, 

complex 

design 

New 
software, 
similar to 
existing 

Significant 

increase 

Significant 
increase in 
number of 
modules 

Schedule 
dependent on 
new system 
performance, 
facility or 
associate 
contractor 

0.9 

High 

State of the 
art, some 
research 
complete 

State of 
the art, 

never 

done 

before 

Extremely 

complex 

Highly 

complex, 

very large 

data bases, 

complex 

operating 

systems 

Performance 
dependent on 
new system 
performance, 
facility or 
associate 
contractor 
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Table 28 - Consequences of Failure (Cf) Rubric 


Consequences of Failure (Cf 

) 

Magnitude 

Technical Factor 
(Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

0.1 

Low 

Minimal or no 
consequences, 
unimportant 

Budget estimates 
not exceeded, 
some transfer of 
money 

Negligible impact on 
program, slight development 
schedule change 
compensated by available 
schedule slack 

0.3 

Minor 

Small reduction in 
targeted technical 
performance 

Cost estimates 
exceeded budget 
by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in 

technical 

performance 

Cost estimate 
increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant 
degradation in 
technical 
performance 

Cost estimates 
increased by 20 
to 50 percent 

Significant development 
schedule slip 

0.9 

High 

Technical goals 
cannot be achieved 

Cost estimates 
increased in 
excess of 50 
percent 

Large schedule slip that 
affects segment milestones 
or has possible effect on 
system milestones 


Using the methodology deseribed, a risk factor for each of the alternative under 
consideration was developed. Each alternative was evaluated without modifying the 
SATCOM radio frequency transport and an enhanced version of the SATCOM radio 
frequency transport. A summary of the derived risk factors are provided in Table 29, Risk 
Factor Comparison of Alternatives. The individual sub risk assignments and tabular data 
for each solution are provided as Appendix B for reference. 
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Table 29 - Risk Factor Comparison of Alternatives 


Alternative 

Risk Factor (RF) 

SATCOM 

Standard 

Throughput 

SATCOM 

Enhanced 

Throughput 

Alternative 0 - Baseline 

0.28 

Low 

0.72 

High 

Alternative 1 - DiflServ 

0.54 

Medium 

0.86 

High 

Alternative 2 - MPLS 

0.54 

Medium 

0.86 

High 

Alternative 3 - Router Upgrade 

0.68 

Medium 

0.89 

High 

Alternative 4 - Dedicated C2 Routers 

0.86 

High 

0.94 

High 

Alternative 5 - Upgraded routers 
w/MLPS 

0.70 

Medium 

0.81 

High 

Alternative 6 - Clearing House 

0.63 

Medium 

0.85 

High 

Risk Factor Assignment Legend 

0.7<RF< 1.0 

High Risk 

0.3 <RF<0.7 

Medium Risk 

0.0<RF<0.3 

Low Risk 


B, RISK SUMMARY 

The risk assessment provides a doeumented methodology and results that are 
obtained systematically, complete, unbiased and transparent. In executing this 
methodology, constraints, uncertainties and assumptions are considered at each step in 
the assessment process and documented. The output of this risk assessment is to present 
risk management options with an evaluation of each alternative that supports the decision 
making process of the project management. 

The baseline risk factor is one of the six alternatives, but is provided for 
information only. The risk factor baseline of 0.28 is a low risk and represents the “as-is” 
system that may meet C2 requirements in the short term. However in the long term one 
could propose this option is higher and boarders on high risk if C2 requirements of the 
future dramatically increase and this option chosen. Under the latter assumption, the 
baseline choice is essentially not an option from the risk perspective. 

Although the alternatives under investigation focus on data transport through 
predominately “wired” networks, each alternative is also paired to a pseudo seventh 
alternative of increasing data transport across radio frequencies in the super high 
frequency band utilizing satellite communication methodologies. The alternative is 
considered pseudo as it is a non option because of the magnitude of the cost and schedule 
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increase above the assumptions of this assessment. Thus the information is included as 
an informational investigation as to the risk assoeiated when combining two distinct 
solutions that are normally segmented. 

As shown previously, alternatives one and two have the lowest risk factor among 
the group. This is reasonable as the application of the software routing protocols into the 
existing system is similar and the minimal hardware upgrades do not drive up the risk of 
one ehoiee over the other. Key to managing either of these efforts is the major software 
ehanges, dependency of the performanee on existing systems and the potential for 
signifieant development schedule slip. Next, alternative six, clearing house, provides 
reduced development cost compared to the other alternatives, however software 
eomplexity is a high risk forcing function that may impact and render the eost benefits 
null if not managed vigorously by the project management team with an appropriate 
abatement plan. Increasing in risk, alternatives three and live, router upgrade and router 
upgrade with MLPS, are at the upper scale of the medium risk primarily as a result of 
performanee being highly dependent on the installation of completely new hardware. 
Likewise, with alternative six, will require an appropriate abatement plan be developed 
and executed to prevent performance degradation during implementation. 

Alternative four and the SATCOM bandwidth increase coupled with any option is 
elearly high in risk. Restraint and eaution should be exercised prior to proceeding with 
any of these options. If performance dictates one of these options as the only viable 
solution, another detailed risk analysis must be performed. The new analysis 
methodology should be tailored to the specifics of that type of complex undertaking. 
New attributes and weighting should be introduced into the present method to further 
characterize the risk assoeiated with SATCOM, eost control and the complexity of 
managing extremely large seale projeets. 
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X. SUMMARY AND RECOMMENDATIONS 


A. SUMMARY 

The project team employed a MBSE approach to document the requirements, 
define the operational architecture, define high level functions that the networks must 
support, and model different system of system alternatives. Naval Warfare Publications, 
Navy Tactics, Technique and Procedure Publications and leadership writing were 
analyzed to refine a set of coincide technical performance measure that navy networks 
need to satisfy to support Fleet Battle Management. These key measures are: 

a. Delay time for propagation of vital situational awareness information 
throughout the network 

b. Percentage of time soft-real-time requirements that can be maintained 
throughout the network 

c. Percentage of time hard-real-time requirements that can be maintained 
throughout the network 

Fleet stakeholders were engaged throughout the process to develop a value system based 
on these concise measures that was used to analyze these alternatives. 

The project team researched how other industries might address the issue of 
meeting the key measures. It was discovered that the Global banking System employs 
architectures and technology in order to address many of the same requirements. A 
concept of a transaction clearing house was identified as an alternative way to build 
trusted transactions between operational nodes enhancing Command and control and 
improving fleet battle management 

The project developed a representation of the operational functional architecture 
using the Vitech CORF system engineering toolset. A huge advantage to this approach is 
the ability to model the effect of operational activities and organization with respect to 
meeting the key measures. A significant finding was that the organizational construct had 
significant impact on how well Fleet Battle Management can be supported. 

The Joint Communication Simulation System (JCSS) toolset was utilized to 
develop a physically representative model to understand how different networking 
architectures could be employed. Since there are copious alternatives to model, a Design 
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of Experiments approaeh was adopted to obtain data on several signifieant permutations 
with data extrapolation used to score effectiveness of some solutions. 

The project team performed a cost analysis and assessment of risk, both from 
aspect of vulnerability to operational threats and cost/schedule/performance 
considerations to all alternatives. A summary of the alternatives along with scores for 
benefit, risk, and estimates of Life Cycle Cost is provided in Table 30. 


Table 30 - Summary of Alternatives Considered 


ALTERNATIVE 

Benefit 

(Normalized 

Score) 

Risk 

(Normalized 

Score) 

Life Cycle 

Cost Estimate 

($M) 


NETWORK 

SATCOM 

1. 

Baseline (current 

systems) 

Baseline 

(current systems) 

0.1 

0.28 

(low) 

8,991 

2. 

Baseline (current 

network systems) 

Upgrades 

0.09 

0.72 

(high) 

135,356 

3. 

Implement 

DiflServ 

Standard 

0.06 

0.54 

(med) 

8,997 

4. 

Implement 

DiflServ 

Upgraded 

0.05 

0.86 

(high) 

135,362 

5. 

Implement MPLS 

Standard 

0.04 

0.54 

(med) 

9,019 

6. 

Implement 

MPLS 

Upgraded 

0.03 

0.86 

(high) 

135,374 

7. 

Upgrade Routers 

Standard 

0.08 

0.64 

(med) 

9,052 
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8. 

Upgrade Routers 

Upgraded 

0.07 

0.87 

(high) 

138,495 

9. 

Dedicated C2 

Routers 

Standard 

0.13 

0.86 

(high) 

9,074 

10. 

Dedicated C2 

Routers 

Upgraded 

0.12 

0.94 

(high) 

135,362 

11. 

Upgraded Routers 

w/MPLS 

Standard 

0.11 

0.70 

(high) 

9,122 

12. 

Upgraded Routers 

w/MPLS 

Upgraded 

0.10 

0.81 

(high) 

138,511 

13. 

Clearing House 

Standard 

0.02 

0.61 

(med) 

5,177 

14. 

Clearing House 

Upgraded 

0.01 

0.85 

(high) 

131,594 


B, RECOMMENDATIONS 

Based on the analysis and methodology presented for this project, the project 
team makes the following recommendation for naval investment strategy in Fleet battle 
Management. 

1. Dedicated C2 Routers 

The project team recommends in augmenting current ashore and afloat networks 
with dedicated routers (having standard performance capability as currently fielded 
router) dedicated to carrying C2 traffic. While Navy networks have aided in the ability 
for Navy operational and tactical forces to rapidly share information, the concern the 
project team has with the current operational and tactical seam is that critical command 
and control data can be significantly delayed with general traffic when networks and 
communications channels become saturated. While adding satellite communications 
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capacity will aid data throughput, it in itself does not appear to address any of the key 
measure for effeetive fleet battle management. 

2, More Research into Clearing House Architectures 

The funetional; and physieal models for the data elearing house approaeh did not 
show remarkably better improvement for fleet battle management over existing networks. 
However this approaeh was the one alternative that offers US Navy signifieant eost 
avoidanee by redueing Operations and Support eosts. The projeet team reeommends that 
this approaeh for C2 warrants further study to see how information exehanges and 
organizational tuning ean better utilize the elearing house approaeh. 

C. AREAS FOR FURTHER STUDY 

1. Data Pedigree 

Discussions with the Teehnieal Director for PMW150 identified a need for 
establishing and maintaining data pedigree within the C2 information systems. This is 
driven by the need to further enhance the commander’s trust in the information presented. 
The investigation of data pedigree would necessitate an excursion into the realm of Data 
Engineering and would thus be beyond the scope of this project. Further investigation, 
however, would be warranted in this area to support the ability of the commanders across 
echelons to self-synchronize as operational and battle plans are executed. The hypothesis 
would be that speed of command would be enhanced by providing decision makers with 
information that included a level of metadata that would readily indicate the level of 
goodness, or proximity to reality of the current battlespace state. 

2, Detailed Operational Timelines 

As discussed in earlier paragraphs, the Functional Analysis did not delve into 
analysis of time and resources (people, bandwidth, etc.) of various Command and Control 
function to alleviate any concerns of data classification. The project team acknowledges 
that without such fidelity, the analysis will not discover where there maybe be 
bottlenecks or blocking conditions that can impede effective Command and Control. 
This would be a meaningful study objective. 
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3, Human Factors and Cognitive MOPs and MOEs 

While there is a reeognition that the eognitive aspeets of eommand and eontrol 
and its assoeiated deeision making aspeets eannot be ignored, treatment of these aspects 
in depth is beyond the scope of this project. Li Niu, et al assert that a framework can be 
applied to cognition driven decision support in the business domain using a conceptual 
framework (Niu, Lu, and Zhang 2009). This framework, shown in Figure 34 establishes a 
series of relationships that have situational awareness and mental models at the core of 
the decision making process. This concept could be very useful in understanding the 
cognitive architecture capabilities and limitations, and thus provide for the development 
of MOPs and MOEs that can be applied to Agile Command and Control. 



Figure 45 - Cognitive Driven Processes [From Niu, Lu, and Zhang 2009] 


4, Data Perishability & Clutter 

In the course of conducting research and investigating the various excursions of 
the technical architectures, the concept of data perishability was identified. What is 
meant by data perishability is the association of data value degradation over time. The 
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hypothesis in this case would assert that certain types of data becomes less valuable to the 
commander and the decision process as time goes by. While the capstone project afforded 
some analysis in the prioritization of data across the communications infrastructure, 
further analysis into the impacts of data perishability in a dynamic command and control 
environment were not investigated. 

5. Covert Forces 

Predominantly discussions of networked forces it is usually assumed that the 
forces want to be networked and in communications and collaborating. There is a 
segment of naval forces that purposely operate covertly and purposely choose to not 
communicate. Many of the tenets of queued information exchanges with assured 
transactions that are performed in the banking industry (as one example) may apply very 
well to these forces. Integrating this category of forces into a network centric paradigm 
requires further analysis. 

6, Clearing House Approach 

The functional; and physical models for the data clearing house approach did not show 
remarkably better improvement for fleet battle management over existing networks. This 
is likely due to the fact that in order to take full advantage of this approach requires re¬ 
thinking the management model that has been in place for centuries is required. Research 
into the adoption of management models that take full advantage of the services and data 
strategies that can be effectively employed with a clearinghouse is recommended. 

D, Concluding Remarks 

The project team embarked on a investigation to determine how to improve fleet 
battle management using alternative networks designs and architectures While some 
improvement to FBM is likely with investment in technology, a surprise finding was that 
a significant limitation to fleet battle management may lie in the way Navy command and 
control structure are organized. A key limitation may he in the seam between operational 
and tactical level of command. 
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We began this exploration on the seminal writings of VADM Willard whose 
sehooling on the “Art of Command and Control” seemed very fitting to this project. Our 
findings seem to echo VADM words in his 2002 article in Proceedings: 

“We must rediscover the lost art of command and control. Our training 
and developmental emphasis in the Navy and joint forces needs to 
embrace command and control as a fundamental operational task, with 
priority on schooling our commanders in what they must know, where to 
access that information, and how to act on it once they have it to guide the 
operation more effectively. We must better understand what the common 
picture is, what it is not, how to make it available to all levels of the 
command-and-control hierarchy, and how to use emerging technologies to 
exchange relevant, timely information and guidance. Finally, we must 
school commanders on the challenges of controlling more than one 
dynamic operation at once, how to recognize when their ability to guide 
effectively is being overcome, and what actions they might take to ensure 
that on-scene commanders continue to receive the assistance they need to 
advance their plans.’’(Willard 2002) 

In our final closing remarks for this research, the following words penned in 1915 by 
LCDR Dudley Knox apply equally well to our times: 

“To reach the ultimate goal of war efficiency we must begin with principles, 
conceptions and major doctrines, before we can safely determine minor doctrines, 
methods and rules. We must build from the foundation upwards and not from the 
roof downwards. 

For example, it is important to determine whether our strategic and tactical 
operations shall be offensive or defensive in character, and whether they are to be 
introduced by “secondary warfare” (mines, destroyers and submarines) or by 
“primary warfare” (the employment of the whole force); whether the fleet will 
form in ordinary simple column or in an alignment of groups; whether a parallel 
fight is to be sought or a concentration of superior force at one or more points. 
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and if the latter how and where; whether eaeh type of ship will be eoncentrated or 
the whole force divided into groups, each comprising several types; whether we 
will attempt to fight by exterior or interior lines; whether destroyers are to 
endeavor to cripple the enemy by a night attack preceding the general engagement 
or to be used only during the main fleet action; whether submarines shall adopt 
eccentric plans or be utilized jointly with the rest of the fleet; whether information 
is to be obtained by wide flung distant scouting or only by close scouting; whether 
our system of command is to provide the freedom of the initiative to subordinate 
commanders or will depend upon centralized direction by the commander-in- 
chief, etc.’’(Knox 1915) 
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1.0 Project Introduction 

This is the Project Management and Systems Engineering Plan (PM&SEP) for the 
Space and Naval Warfare Systems Command (SPAWAR) Cohort 311-092W, Capstone 
Project. As part of the Naval Postgraduate School (NPS) Master of Science in Systems 
Engineering (MSSE) Capstone Project, the Capstone Project team will examine the 
Measures of Performance (MOP), Measures of Effectiveness (MOE), and Quality 
of Service (QoS) Characteristic required to support an Agile and Network 
Centric Command and Control Organization. 

1.1 Project Description 

This Capstone Project topic was selected to support the Deputy Chief of Naval 
Operations (DCNO) for Information Dominance (N2/N6) roadmap effort. Under this 
effort, the DCNO has identified a set 14 mission/capability roadmaps; 

■ Undersea Dominance 

■ Every sensor is networked 

■ Maritime Ballistic Missile Defense Command and Control 

■ Maritime Domain Awareness 

■ Intelligence, Surveillance, and Reconnaissance 

■ Unmanned Aircraft Systems 

■ Cyber 

■ Fleet Battle Management 

■ Integrated Surface Sensors 

■ Electromagnetic Spectrum 

■ Air Dominance 

■ Strike Command and Control 

■ Decision Superiority 

■ Spectrum Usage 

■ Convergence to a Single network 
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The topic of this Capstone will address Fleet Battle Management. The hypothesis 
that Fleet Battle Management (FBM) technologies, tactics, processes and procedures may 
benefit from the incorporation of some of the “game changing” transformational 
technologies articulated in the Chief of Naval Operations (CNO) Information Dominance 
vision has not been evaluated with systems engineering rigor. Proper evaluation requires 
the definition of MOPs and TPMs associated with FBM success, the identification of 
gaps or shortfalls in current and programmed approaches, development of sufficiently 
detailed architectural alternatives, the construction of performance models, and the 
performance of high-level analyses and optimization of candidate solutions for both 
capability and Total Ownership Cost. 

1.2 Project Objective 

This project will examine the MOP, MOE, and QoS characteristics required 
supporting an Agile and Network Centric Command and Control organization. The 
spectrum of Doctrine, Organization, Training, Feadership, Materiel, Personnel, and 
Facilities (DOTMFPF) considerations will be examined. 

1.3 Project Team 

The Project team is comprised of the following members dispersed on opposite 
shores of the United States: 

Fernando DeJesus SPAWAR System Center Pacific 56130; San Diego, CA 
Roger Gray SPAWAR System Center Atlantic 58360; Charleston, SC 

Stewart Hall SPAWAR Headquarters 5.0.5; San Diego, CA 

Benjamin McCoy SPAWAR System Center Pacific 55230; San Diego, CA 

Nazila Rashed SPAWAR System Center Pacific 55130; San Diego, CA 

Steve Roa SPAWAR System Center Pacific 53040; San Diego, CA 

Antonio Siordia SPAWAR System Center Pacific 84100; San Diego, CA 

Mike Shirley SPAWAR System Center Atlantic 56150; Charleston, SC 

Adam Wolf SPAWAR System Center Atlantic 55210; Charleston, SC 

Charles Wood SPAWAR System Center Atlantic 56150; Charleston, SC 
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1.4 NPS Faculty A dvisors 

1.4.1 Lead Advisor and Systems Engineering Advisor 

The Lead Advisor for this Capstone Project is Dr. Donald S. Muehlbach Jr. 
Professor of Practice Department of Systems Engineering Graduate School of 
Engineering and Applied Sciences. 

1.4.2 Electrical and Computer Engineering Advisor 

The Electrical and Computer Engineering Advisor for this Capstone Project is Dr. 
Weilian Su Associate Professor Advanced Networking Laboratory Department of 
Electrical and Computer Engineering Naval Postgraduate School. 

1.5 PM & SEP Updates 

This project management and Systems engineering plan is a living document and 
will be updated as needed throughout the Project duration. At a minimum this 
Management and Systems Engineering Plan will be updated during the first week of 
every academic quarter until the project is completed. This plan will be updated in the 
event of (but not limited to) the following occurrences: 

a. Change in team composition 

b. Changes in project scope or objective 

c. Change in stakeholder needs 

d. Changes to project incorporated after scheduled In Process Review 

Changes will be approved by NPS Eaculty advisors then codified in this plan, and then be 
signed by the project team. Change rationale will be noted in the change history of this 
document. 

1.6 Applicable Documents and References 

Naval Post Graduate School. Capstone Project Guide DL SE Programs. Monterey: 
Department of Systems Engineering Naval Postgraduate School, 2006 

University of Chicago Press. The Chicago Manual of Style. 15* ed. Chicago: University 
of Chicago Press, 2003 
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International Council on Systems Engineering. Systems Engineering Handbook: A Guide 
for System Life Cycle Processes and Activities, ver 3.1. 2007 

Steven H. Dam. DoD Architecture Framework: A Guide to Applying Systems 
Engineering to Develop Integrated, Executable Architecture. Marshall: System and 
Proposal Engineering Company, 2006. 

Office of the Secretary of Defense, Risk Management Guide for DoD Acquisition. 6th ed 
(ver 1.0). 2007 http://www.acq.osd.mil/sse/docs/2006RMGuide4Aug06finalversion.pdf 

DASN C4I, Navy Information Dominance, CNO N2N6EC Concepts and Strategy, 13 
April 2010 
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2.0 Project Management Plan 

2 .1 Project Management Roles & Responsibilities 

The Capstone Project team consists of ten team members who are located at San 
Diego, California and Charleston, South Carolina. Members will share project 
management and systems engineering roles and responsibilities. Table 2-1 outlines the 
project management roles. 


Table 2-1 Project Management Roles and Responsibilities 


Role 

Primary Roles & 
Responsibilities 

Key Responsibilities 

Team Captain 

Stewart Hall 

■ Act as single POC for Team 

■ Lead Planning 

■ Stakeholder Engagement and 

Communications 

Team Co- 

Captain 

Steve Roa 

■ Act as Backup POC for Team 

■ Assist Lead Planning 

■ Assist Stakeholder Engagement 

and Communications 

Project 

Administration 

Nazila Rashed 

■ Maintain Project Schedules 

■ Monitor Critical Path Activities 

■ Maintain communications 

Project Risk 

Manager 

Adam Wolf 

Mike Shirley 

Charles Wood 

■ Risk identification 

■ Risk Analysis 

■ Risk monitoring 

■ Risk Reporting 

Librarian 

Ben McCoy 

Roger Gray 

■ Maintain Sakai website 

■ Maintain data repository 

■ Configuration control of all 

deliverables 
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Role 

Primary Roles & 
Responsibilities 

Key Responsibilities 

Editing 

Fernando DeJesus 

Antonio Siordia 

■ Assembly of Deliverables 

■ Administer quality control 

■ Ensure technical merit and 

cohesiveness 

Charleston Team 

POC 

Roger Gray 

■ Act as primary POC for Charleston 

team to help with coordination 


2.2 Project Cycle Overview 

The project cycle for this Capstone Project is illustrated in Figure 2-1. The 
project will be conducted in four phases: Initial Research, Architecture and Analysis, 
Forming Conclusions and Recommendations, and finally Reporting Results. Each of the 
phases is described in the following subsections. 


Phase 1 

Phase 2 

Phase 3 

Phase 4 

Initial 

Research 

Architecture 
& Analysis 

Form Conclusions & 
Recommendations 

Report 

Results 


Figure 2-1 Project Cycle 


2.2.1 Phase 1: Initial Research 

During this phase, the project team will begin to form and the research topic is 
selected. 
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Table 2-2 Phase One Key Events 


Entrance Criteria 

■ NPS approval of Project Management and System 

Engineering Plan 

■ NPS approval of project topic 

■ Stakeholder acceptance of topic 

Exit Criteria 

■ Peer Review of refined problem statement 

■ Stakeholder acceptance of refined problem statement 

Key Activities 

■ Initial Project Management Plan 

■ Initial Systems Engineering Plan 

■ Selection of Project Topic 

■ Stakeholder engagement 

■ Team Assignments 

Decision Gates 

■ In Process Review One 


While research will continue during all phases of the project, the objective of Phase I is to 
perform the initial research that will reveal the true character of the research problem. 


2.2.2 Phase 2 Architecture and Analysis 

During Phase 2, the project team will perform analysis and modeling of the 
problem. Current thinking, problem decomposition, and performance modeling will be 
employed to understand and characterize the problem space. It is permissible if there is 
overlap between this phase and research phase. However, the Project team must ensure 
that the research phase does not extend itself and risk timely initiation of the architecture 
and analysis phase. Table 2-3 breaks down the events for this phase. 
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Table 2-3 Phase Two Key Events 


Entrance Criteria 

■ Research has characterized the problem 

“what about the current situation is unsuitable” 

■ Potential approaches have been identified to permit 

modeling and analysis 

Exit Criteria 

■ Peer Review of refined problem statement 

■ Stakeholder acceptance of refined problem statement 

Key Activities 

■ Updated Project Management Plan 

■ Updated Systems Engineering Plan 

■ Operational Architectures 

■ System Architectures 

■ Value System Development 

Decision Gates 

■ In Process Review Two 

■ Stakeholder acceptance of value system 


2.2.3 Phase 3 Conclusions and Recommendations 

During Phase 3, the Capstone Project team will synthesize the problem analysis 
and recommend solutions and possibilities for continued research. Table 2-6 illustrates 
the resulting actions required to complete a phase. 
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Table 2-4 Phase Three Key Events 


Entrance Criteria 

■ Architecture is complete 

■ Value System is complete 

■ Data obtained from models 

Exit Criteria 

■ Project Report 

Key Activities 

■ Data analysis 

■ Eife cycle cost estimates 

■ Generation of project report 

Decision Gate 

■ Peer review of draft report 

■ Stakeholder acceptance of draft results 


2.2.4 Phase 4 Reporting Results 

During Phase 4, the Capstone Project team will report the results to NPS Staff and 
project stakeholders. Table 2-5 describes the resulting actions to complete a phase. 


Table 2-5 Phase Four Key Events 


Entrance Criteria 

■ Capstone Report is complete 

Exit Criteria 

■ End of Academic Quarter 

Key Activities 

■ Project Brief 


■ Report to stakeholders 


■ Report to NPS staff 

Decision Gate 

■ Report peer review 


■ Brief peer review 
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2.3 Project Milestones & Deliverables 

Key deadlines and proposed deliverables will be used to measure the progress of 
this project as well as provide recordable artifacts. Table 2-6 lists the deliverables for this 
Capstone Project. 

Table 2-6 List of Deliverables 


Due Date 

Deliverable 

Description 

Key Products 

16 April 2010 

Draft PM & SE plan 

■ Project management process 

outline 

■ System engineering process 

outline 

7 May 2010 

PM & SE Plan 
(Version 1) 

■ Problem Statement 

■ Tailored system engineering 

process 

■ Tailored management process 

21 May 2010 

IPR# 1 

■ Effective needs statement 

■ User Requirements 

■ Results of initial research 

■ Risk Assessment 

21 July 2010 

PM & SE Plan 
(Version 2) 

■ Revised problem statement 

■ Revised management process 

■ Revised systems engineering 

process 

10 Sep 2010 

IPR #2 

■ Updates from IPR #1 

■ Architectures 

■ Eunctional Modeling 

■ Initial Alternatives 

identification 
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Due Date 

Deliverable 

Description 

Key Products 

12 Oct 2010 

PM & SE Plan 
(Version 3) 

■ Revised problem statement 

■ Revised management process 

■ Revised systems engineering 

process 

10 Dec 2010 

IPR#3 

■ Updates from IPR #2 

■ Summary of engineering 

products (Architectures, 

Punctional Modeling, User 

requirements. Analysis of 

Alternatives, etc) 

■ Recommendations 

09 Dec 2010 

Pinal Project Report 

■ Pinal Project Report 


2.4 Stakeholder Engagement 

Stakeholder engagement is a principal component of identifying the problem 
statement. With their direction, vision, and advice, preliminary requirements can be 
created and help establish a base point to begin a project. Table 2-7 summarizes the 
stakeholders that are expected to be involved during this Capstone Project. Also 
indicated are expected interactions and indication of how familiar the team is with the 
stakeholder. 
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Table 2-7 Stakeholder Summary 


Stakeholder 

Organization 

Anticipated Involvement 

Familiarity 

Dr Bill Rix 

SPAWAR5.1 

■ MOP & MOE 

Refinement 

■ Architecture 

■ Modeling Requirements 

Consultation 

■ Study customer 

High 

Mr. Bob 

Stephenson 

CPF N6 

Technical 

Advisor & C2 

Technical 

Warrant 

■ MOP & MOE 

Refinement 

■ Architecture 

■ Requirements Value 

System 

Medium 

Dr Rich Jaffee 

C2 

Competency 

National Lead 

■ MOP & MOE 

Refinement 

■ Architecture 

■ Requirements Value 

System 

High 

CDR 

Higginbotham 

OPNAV 

N2N6F42 

■ Study customer 

Low 

Dr Marv 

Langston 

Former DASN 

C4I 

■ MOP & MOE 

Refinement 

■ Architecture 

■ Lifecycle Cost 

Estimation 

Medium 
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Stakeholder 

Organization 

Anticipated Involvement 

Familiarity 

RADM 

Hamlin 

Tallent (ret) 

Eormer 

Commander 

EUCOM 

■ MOP & MOE 

Refinement 

■ Architecture 

■ Requirements Value 

System 

Medium 


During the course of this Capstone Project, additional stakeholders may be identified and 
incorporated into a revision of this PMP. 

2.5 Project Risk Management 

In conjunction with the fundamental objectives of the project being defined, 
fundamentals of risk planning will be executed. It is anticipated that planning will follow 
the guidance of the DoD Risk Management Guide and INCOSE version 3.1 to employ a 
tailored risk management process throughout all phases of the project. The basic process 
is composed of five phases: Identification, Analysis, Mitigation, Implementation, and 
Tracking as outlined in Eigure 2-2. Each phase will be described in more detail 
accordingly. The development of a risk management plan is currently being evaluated. 
The risk management plan, if implemented, will contain details of the process, provide 
instruction for proper tracking and define roles and responsibilities of project participants 
with respect to risk. All team members are charged with identifying potential risks and 
bringing them to the attention of the group. Once issues are brought forth, it will be the 
responsibility of the risk control board to separate risks from issues; validate those risks 
and apply project resources accordingly. The following paragraphs provide a high level 
description of each phase in the risk management cycle. 
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Identification 

•What can go 
wrong? 


f ^ y 

Tracking 

• Doucmentation 
and Reporting 

V_ J 


Risk Analysis j 

Management 

Cycle J 





y y 

Implementation 


Mitigation 

• Is it working? 


• How can the risk 
be reduced? 

V J 

V 

J 




Figure 2-2 Project Risk Management Process 

2.5.1 Risk Identification 

Early risk identification is critical and vital for effective risk management. It is 
the fiduciary duty of any project team member, faculty advisor, or stakeholder to identify 
and enter risks into the management process. A risk may be defined as an uncertain 
event which may cause an execution failure in the program. It is the possibility of loss, 
injury, disadvantage, or anything that has a negative impact on a program. It is a measure 
of the inability to achieve program objectives. Risk has two components: a probability of 
the event occurring and a consequence if the event occurs. The criticality of these two 
components will be evaluated to determine the effects of risks on the program. In 
reporting, whenever possible, risk statements should be expressed (or transformed) into if 
(situation) then (consequence) format. Each member will have access to the risk 
identification form to assist identification and introduction into the risk process. 
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2.5.2 Project Risk Analysis 

In order to assess the risks and apply resources appropriately, it is critical that the 
risk assessment contains both quantitative and qualitative assessments of the various risks 
occurring and their impact on costs, schedule adjustments, and effective performance. 
The risk management plan contains guidance for assessing the impact of each risk and 
applying measurements to prioritize the relative risk. Details of the assessment model are 
provided in the risk management plan. 

2.5.3 Project Risk Mitigation 

To minimize severity of identified risks, the Project team will develop mitigation 
plans for every identified and approved risk. Risk mitigation or risk handling approaches 
will include the traditional options such as: control, avoid, assume, and transfer. The 
strategy for risk mitigation will vary depending upon the severity of risk, number of risks, 
and impact to stakeholders. In general as the project schedule cannot be relaxed, the most 
likely mitigation will be to refine the project scope. In some instances stakeholders will 
need to be notified. The key is proactive identification and risk management to ensure 
the project is successful completed and accepted by NPS and meets stakeholder 
expectations. 

2.5.4 Project Risk Implementation 

The Project Risk manager and team will insure that the implementation process is 
a part of the day-to-day workings of the project. To be successful, the team is adopting a 
continuous assessment process in which all members have access to risk information and 
current mitigation efforts. Although risk management is engrained in our system 
engineering process, the risk manager will provide focused attention on active risks 
identified by the risk control board. 

2.5.5 Risk Monitoring and Reporting 

Risks will be posted on the team shared information repository on Sakai. Sakai is 
the NPS Collaborative Learning Environment, and is available to all members. Initially, 
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risks will be documented in accordance with the risk management plan using the 
approved forms and processes. The risks identified will be logged by the risk control 
board and entered into a log sheet that will provide high level metrics, status and 
references back to the risk initiation form. In addition to the risk form and tracking log, 
major risks will be presented in a graphical format as illustrated in Figure 2-3. The 
Project Risk Manager’s report will include the status of risks, risk mitigation and 
progress. It will also be the risk manager’s responsibility to provide information and 
assistance as needed during team meetings and discussions. 

The risk management team is currently evaluating the use of software tools such 
as Risk Radar, Risk++ and Risk Exchange to aid in executing the risk management 
process. The cost, availability and applicability will be critical attributes in choosing the 
proper support tool. Until support software is available, risks will be documented and 
tracked through traditional means such as approved risk forms. Excel tracking sheets and 
PowerPoint graphics. 



Figure 2-3 Risk Analysis Assessment Model 
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2.6 Project Schedule 

The Program Evaluation and Review Technique (PERT) Critical Path Method 
(CPM) will be employed to develop a project master schedule. The master schedule will 
be created using an Office Project file. The master schedule serves as a tool for 
evaluating project maintenance and reporting, as well as itemizes tasking needed for 
meeting each milestone date within each of the major cycle periods. 


2.6.1 Project Schedule Maintenance and Reporting 

The Capstone Project Administrator will maintain the project schedule. The 
schedule will be kept updated on at least a weekly basis. The project schedule will be 
formally reported during planned IPRs. The Project Administrator will also report 
schedule changes as needed during team meetings and discussions. 

2.6.2 Project Master Schedule 

Extracted from the detailed master project schedule, there are five major periods 
identified within the project cycle. The first period identifies the Information and 
Gathering phase where preliminary ideas, data, and backgrounds are collected to 
formulate a problem statement and cumulating into a Project Management Plan. Concept 
Development soon follows with a more detailed description of the scope and stakeholder 
needs. Concept development outlines the boundary of the problem space. After further 
research, functional analysis and architectural design are crafted within the engineering 
development period. As a result, design recommendations and project summaries are 
evaluated and adjusted into a Conclusion and formally into a Pinal Report. An outline of 
the schedule for this Capstone Project is provided in Pigure 2-4. 
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Team Schedule 

■■■ Quality of Service Required to Support Agile Command and Control Project 


Key Dates 


Spring 2010 

Summer 2010 

Fall 2010 

April 

May 

June 

July 

August ; September 

October : November ; December 
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Development 

Recommendations 
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Final Report 


AA 


Draft final 
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A. 


A 


Problem 
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A 


Stakeholder Needs. Requirements. Alternatives. 
Gap and Functional Anah sis 


A 


Functional Anairsis and Architecture Development 


Design Recommendations / Project 
Summon 




Final Report Due 

AA 


Final Report Write Vp 


1 

Figure 2-4 Project Schedule (05/09/2010) 


2.7 Deliverable Quality Control 

The Project Editors will be responsible to ensure all deliverables meet the 
required format and content requirements. All deliverables will be provided to the 
project editors prior to submission. 


2.8 Project Communications Plan 

The Project team is divided between east coast and west coast members. This 
creates challenges in work synchronization and communication. The following 
procedures are designed to minimize this challenge: 

a) Weekly Drumbeat Conference Calls to maintain communication 

b) Use of Online collaboration websites (DCO) 

c) Use of Sakai for primary document hosting 
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d) Use of VTC capability during class sessions 

e) Distributed team management 


24 




Project Management and Systems Engineering Plan 


3.0 Systems Engineering Plan 


3.1 Systems Engineering Process Overview 

The Project team will follow a tailored system engineering process based on the 
process described in; DoD Architecture Framework - A Guide to Applying Systems 
Engineering to Develop Integrated, Executable Architectures. The process will allow the 
project team to apply model base system engineering analysis to define the problem and 
present a solution during the time allotted. Figure 3-1 illustrates this process. 


/-^ 

Conduct Research 

• Define Operational Scenarios 

• Determine candidate systems 
♦Assumptions & Constraints 

• Effective Need 

V_ 

/ 


Functional Analysis 

• Define functions 

• Functional allocation 




Figure 3-1 Project Systems Engineering Process 
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3.1.1 SE Process tradeoff Variables 

In order to determine what the correct SE process should be for the Capstone 
project, a set of measures of goodness need to be developed. These will become the 
tradeoff variables to choose the proper SE process. The tradeoff variables are listed 
below. 


■ Risk Mitigation: The SE process implemented by the team must aid in risk 
mitigation throughout the Capstone project lifecycle. This can be measured as 
the probability of defined project requirements being delivered under known 
timelines with a specific defined risk. 

■ Quality Eevels: The SE process must ensure that the products being created are 
meeting quality levels thereby limiting schedule growth. This could be measured 
as a percentage of deviation from quality thresholds set by the internal and 
external stakeholders. 

■ Eead Time: Due to the strict nature of our schedule, we have to meet the final 
report submission deadline of early December. The ideal SE process will limit 
the average amount of time from the defined inception point until the defined 
delivery point. 


3.1.2 Candidate Process Evaluation 

The following processes were evaluated and weighted according to their 
advantages and disadvantages for this Capstone project: 


■ Steven Dam’s process (modified) 

■ Army SE process 

■ Classic Vee model 

■ Kossiakoff and Sweet 

■ INCOSE SIMILAR (modified) 

After final consideration, a modified version of Steven Dam’s process was selected as the 
recommended SE process to be used for this Capstone project. The figure below 
describes the modified process. 


26 





Project Management and Systems Engineering Plan 


Steven Dam’s process 


1. Capture and analyze related documents 


2. Identify assumptions 


5. Develop the operational context diagram 


6. Develop operational scenarios 


7. Derive functional behavior 


I I Requirements analysis 

I I Functional analysis 
□Synthesis 
□System Analysis & 
Control 


4. Capture constraints 


3. Identify existing/planned systems 

14. Provide options 


12. Perform dynamic analysis 


11. Define resources, error detection & recovery 

13. Develop Op Demo master plan 

15. Conduct trade-off analyses 

16. Generate OV’s & SV’s, and reports 


Figure 3-2 Project’s Modified Steven Dam’s Process 


The allocate function to systems element and prepare interface diagrams portion of the 
SE process, was deleted as this was a part of synthesis which the team will not be doing 
as part of the capstone project. The Dam process clearly shows where the center of effort 
is by using horizontal time scale to depict the systems engineering lifecycle. Another 
advantage of the Dam process is that it allows for parallel development of various 
analysis products which help optimize the lead time. Quality levels are addressed with 
peer reviews of interim deliverables during the lifecycle. While the process does not 
explicitly show risk mitigation in the diagram, this occurs in every phase of the process 
through risk identification, planning, and mitigation activities. Eor further information on 
the risk process please consult the team’s risk planning guide. 
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3.2 Systems Engineering Roies & Responsibiiities 

Within the Capstone Project, six identified Functional roles have been identified 
and separately assigned to each team member with the exception of research work being 
done by all members. Table 3-1 identifies these roles. 

Table 3-1 Project Management Roles and Responsibilities 


Role 

Primary Roles & 
Responsibilities 

Key Responsibilities 

Research 

All 

■ Define Operational Scenarios 

■ Determine candidate systems 

■ Assumptions & Constraints 

■ Effective Need Definition 

Functional 

Analysis 

Fernando DeJesus 

Antonio Siordia 

■ Define functions 

■ Functional allocation 

■ Interface identification 

Dynamic 

Analysis 

Mike Shirley 

Adam Wolf 

Fernando DeJesus 

■ Model functions 

■ Performance & limitations 

■ Determine possible error sources 

Tradeoff 

Analysis 

Antonio Siordia 

Adam Wolf 

Steve Roa 

■ Fogistics & Support Considerations 

■ DOTMFPF Considerations 

■ Make or Buy Analysis 

■ T&E Considerations 

Fifecycle Cost 

Analysis 

Antonio Siordia, 

Nazila Rashed 

■ Fifecycle Cost Estimation 

■ CAIV Analysis 

■ Economic Analysis 

Configuration 

Manager 

Benjamin McCoy 

Roger Gray 

■ Act as single POC for Team 

■ Fead Planning 

Project 

Architect 

Stewart Hall 

Fernando DeJesus 

Charles Wood 

Mike Shirley 

■ Defining Operational need 

■ Architecture Synthesis 
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3.3 Model Based System Engineering Tools 

This Capstone Project will use model-based systems engineering techniques for 
refinement, analysis, and traceability of requirements and architectures. Table 3-2 
identifies some of the proposed tools that will be used. 


Table 3-2 Model-Based Systems Engineering Tools 


Manufacturer 

Name 

Application 

Vitech 

CORE 

■ Architectures View Development 

■ Requirements definition 

■ Requirements traceability 

■ Modeling & Simulation 

Microsoft 

Xcel 

■ Modeling and simulation 

Imagine That Inc 

ExtendSim 

■ Modeling and simulation 


3.4 Project Configuration Management Plan 

All Capstone Project deliverables will be based on referenced documentation such 
as research artifacts, architecture views, modeling and simulation results, inter alia. It is 
critical that these products be identified, archived, and properly referenced in all project 
output. The Capstone Project Configuration Manager will be responsible to devise (and 
enforce) a schema that will: 

a) Identify incremental versions of draft documentation 

b) Identify version of deliverables (briefs, reports, etc) 

c) Ensure that research artifacts are archived 

d) Ensure modeling data (data bases, inputs, analysis, analysis) are archived 

e) Historical artifacts and researched are protected and catalogued 

3.5 Project Data Management Plan 

To ensure the integrity of the research and analysis, the Project team will ensure 
that all technical data required independently verifying conclusions, transition results to 
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stakeholders, or enabling future teams to continue this research all necessary data will be 
captured and delivered. This will include (but is not limited to): 

a) Research Artifacts 

b) Architecture Views 

c) Any configuration data for tools 

d) Database inputs and Data output for models 
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APPENDIX B 


RISK ANALYSIS EVLAUATION 


This attachment contains the individual alternative assessment tables and the risk factor 
calculations. Each table is highlighted with the appropriate color indicating the 
assessment for each of the sub risk factor attributes. 
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Risk Analysis Evaluation 


Table 1 - Alternative 0; Baseline - SATCOM Standard Throughput 

RF ^ Risk Factor | 0.28 ~ 

Pf^ Probability of Failure Pf^(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 0.1 

Cf^ Consequence of Failu CfK-5*Ct)+(.3*Cc)+(.2*Cf) 0.20 

RF - Pf + Cf -PfCf 


Probability of Failure (Pf) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

0.1 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor Redesign 

Minor Redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major Change Feasible 

Major Change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology Available, 
Complex Design 

New Software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system perfoimance, facility or 
associate contractor 



State of the Art, some research 
complete 

State of the Art, never done 
before 

Extremely complex 

Highly complex, very large 
data bases, complex operating 
system 

Performance dependent on 
new system performance, 
facility or associate contractor 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

0.1 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical perfonnance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
performance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 



Technical goals cannot be 
achieved 

Cost estimates increased in 
excess of 50 percent 

Large schedule slip that affects 
segment milestones or has 
possible effect on system 
milestones 


Table 2 - Alternative 0; Baseline - SATCOM Enhanced Throughput 
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Risk Analysis Evaluation 


RF = Risk Factor 

Pf^ Probability of Failure Pf^(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.{3*Pcsw)+(.3*Pd) 
Cf^ Consequence ofFailuCfK-5*Ct)+(.3*Cc)+(.2*Cf) 

RF - Pf + Cf -PfCf 


0.44 

0.50 


Probability of Failure (Pf) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

O.l 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor Redesign 

Minor Redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major Change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system perfoimance, facility or 
associate contractor 



State of the art, some research 
complete 

Slate of the art, never done 
before 

Extremely complex 

Highly complex, very large 
data bases, complex operating 
system 

Performance dependent on 
new system performance, 
facility or associate contractor 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

0.1 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
performance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 
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Appendix B 


Risk Analysis Evaluation 


Table 3 - Alternative 1; Diffserv - SATCOM Standard Throughput 

RF ^ Risk Factor | 0.54 

Pf^ Probability of Failure Pf^(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 0.32 

Cf^ Consequence of FailiiCf^(.5*Ct)+(.3*Cc)+(.2*Cf) 0.32 

RF - Pf + Cf -PfCf 


Probability of Failure (PI) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

O.l 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system perfonnance, 
facility or associate contractor 

0.7 

Significant 

Technologyavailable, 

complexdesign 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system performance, facility or 
associate contractor 



State of the art, some research 
complete 

State of the art, never done 
before 

Extremely complex 

Highly complex, very large 
data bases, complex operating 
system 

Performance dependent on 
new system performance, 
facility or associate contractor 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

O.l 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
perfonnance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 



Technical goals cannot be 
achieved 

Cost estimates increased in 
excess of 50 percent 

Large schedule slip that affects 
segment milestones or has 
possible effect on system 
milestones 
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Appendix B 


Risk Analysis Evaluation 


Table 4 - Alternative 1; Diffserv - SATCOM Enhaneed Throughput 

RF = Risk Factor 

Pf= Probability of Failure Pf=(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 

Cf^ Consequence of FailiiCf^(.5*Ct)+(.3*Cc)+(.2*Cf) 

RF - Pf + Cf -PfCf 



Probability of Failure (PI) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

O.l 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system perfonnance, facility or 
associate contractor 



State of the art, some research 
complete 

State of the art, never done 
before 

Extremely complex 

Highly complex, very large 
data bases, complex operating 
system 

Performance dependent on 
new system performance, 
facility or associate contractor 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

O.l 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
perfonnance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 
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Appendix B 


Risk Analysis Evaluation 


Table 5 - Alternative 2; MPLS - SATCOM Standard Throughput 

RF ^ Risk Factor | Q.54 

Pf^ Probability of Failure Pf^(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 0.32 

Cf^ Consequence of FailuCf^(.5*Ct)+(.3*Cc)+(.2*Cf) 0.32 

RF - Pf + Cf -PfCf 


Probability of Failure (PI) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

0.1 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system performance, facility or 
associate contractor 


State of the art, some research 
complete 

State of the art, never done 
before 

Extremely complex 

Highly complex, very large 
data bases, complex operating 
system 

Perfonnance dependent on 
new system performance, 
facility or associate contractor 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

0.1 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
performance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 



Technical goals cannot be 
achieved 

Cost estimates increased in 
excess of 50 percent 

Large schedule slip that affects 
segment milestones or has 
possible effect on system 
milestones 
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Appendix B 


Risk Analysis Evaluation 


Table 6 - Alternative 2; MPLS - SATCOM Enhaneed Throughput 

RF = Risk Factor 

Pf= Probability of Failure Pf=(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 

Cf^ Consequence of FailuCf^(.5*Ct)+(.3*Cc)+(.2*Cf) 

RF - Pf + Cf -PfCf 



Probability of Failure (PI) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

0.1 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system performance, facility or 
associate contractor 


State of the art, some research 
complete 

State of the art, never done 
before 

Extremely complex 

Highly complex, very large 
data bases, complex operating 
system 

Perfonnance dependent on 
new system performance, 
facility or associate contractor 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

0.1 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
performance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 
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Appendix B 


Risk Analysis Evaluation 


Table 7 - Alternative 3; Router Upgrade - SATCOM Standard Throughput 

RF ^ Risk Factor | Q.68 | 

Pf^ Probability of Failure Pf^(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 0.52 

Cf^ Consequence of FailuCf^(.5*Ct)+(.3*Cc)+(.2*Cf) 0.34 

RF - Pf + Cf -PfCf 


Probability of Failure (PI) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

0.1 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system performance, facility or 
associate contractor 

State the some research 

complete 

State of the art, never done 
before 

Extremely complex 

Highly very large 

data complex operating 

system 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

0.1 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
performance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 



Technical goals cannot be 
achieved 

Cost estimates increased in 
excess of 50 percent 

Large schedule slip that affects 
segment milestones or has 
possible effect on system 
milestones 
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Appendix B 


Risk Analysis Evaluation 


Table 8 - Alternative 3; Router Upgrade - SATCOM Enhaneed Throughput 

RF = Risk Factor 

Pf= Probability of Failure Pf=(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 

Cf^ Consequence of FailuCf^(.5*Ct)+(.3*Cc)+(.2*Cf) 

RF - Pf + Cf -PfCf 



Probability of Failure (PI) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

0.1 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system performance, facility or 
associate contractor 

State the some research 

complete 

State of the art, never done 
before 

Extremely complex 

Highly very large 

data complex operating 

system 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

0.1 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
performance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 
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Appendix B 


Risk Analysis Evaluation 


Table 9 - Alternative 4; Dedieated C2 Routers - SATCOM Standard Throughput 

RF = Risk Factor 

Pf= Probability of Failure Pf=(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 

Cf^ Consequence of FailiiCf^(.5*Ct)+(.3*Cc)+(.2*Cf) 

RF - Pf + Cf -PfCf 



Probability of Failure (PI) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

O.l 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system performance, facility or 
associate contractor 

State the art, some research 
complete 

State of the art, never done 
before 

Extremely complex 

Highly very large 

data complex operating 

system 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

O.l 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
perfonnance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 



Technical goals cannot be 
achieved 

Cost estimates increased in 
excess of 50 percent 

Large schedule slip that affects 
segment milestones or has 
possible effect on system 
milestones 
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Appendix B 


Risk Analysis Evaluation 


Table 10 - Alternative 4: Dedicated C2 Routers - SATCOM Enhanced Throughput 


RF = Risk Factor 

Pf= Probability of Failure Pf=(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 

Cf^ Consequence of FailiiCf^(.5*Ct)+(.3*Cc)+(.2*Cf) 0.80 

RF - Pf + Cf -PfCf 



Probability of Failure (PI) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

O.l 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system performance, facility or 
associate contractor 

State the art, some research 
complete 

State of the art, never done 
before 

Extremely complex 

Highly very large 

data complex operating 

system 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

O.l 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
perfonnance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 
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Appendix B 


Risk Analysis Evaluation 


Table 11 - Alternative 5: Router Upgrade with MLPS - SATCOM Standard Throughput 

RF ^ Risk Factor | 0.7Q | 

Pf^ Probability of Failure Pf^(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 0.52 

Cf^ Consequence of FailiiCf^(.5*Ct)+(.3*Cc)+(.2*Cf) 0.38 

RF - Pf + Cf -PfCf 


Probability of Failure (PI) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

O.l 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system performance, facility or 
associate contractor 

State the art, some research 
complete 

State of the art, never done 
before 

Extremely complex 

Highly very large 

data complex operating 

system 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

O.l 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
perfonnance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 


Technical goals cannot be 
achieved 

Cost estimates increased in 
excess of 50 percent 

Large schedule slip that affects 
segment milestones or has 
possible effect on system 
milestones 
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Appendix B 


Risk Analysis Evaluation 


Table 12 - Alternative 12; Router Upgrade with MLPS - SATCOM Enhanced 
Throughput 


RF = Risk Factor 

Pf= Probability of Failure Pf=(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+{.3*Pd) 
Cf^ Consequence of FaiiuCfK-5*Ct)+{.3*Cc)+(.2*Cf) 

RF - Pf + Cf -PfCf 


0.35 

0.70 


Probability of Failure (Pf) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Eactor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

0.1 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system performance, facility or 
associate contractor 

State the art, some research 
complete 

State of the art, never done 
before 

Extremely complex 

very large 

data complex operating 

system 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

0.1 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical perfonnance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
performance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical perfonnance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 


Technical goals cannot be 
achieved 
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Appendix B 


Risk Analysis Evaluation 


Table 13 - Alternative 5: Clearing House - SATCOM Standard Throughput 

RF ^ Risk Factor | 0.63 | 

Pf^ Probability of Failure Pf^(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 0.46 

Cf^ Consequence of FailiiCf^(.5*Ct)+(.3*Cc)+(.2*Cf) 0.32 

RF - Pf + Cf -PfCf 


Probability of Failure (PI) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

O.l 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system perfoimance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system performance, facility or 
associate contractor 

State the art, some research 
complete 

State of the art, never done 
before 

Extremely complex 

Performance on 

system performance, 

^^^^^^^^^^^^^^^^^Hfacility or contractor 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

O.l 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
perfonnance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 



Technical goals cannot be 
achieved 

Cost estimates increased in 
excess of 50 percent 

Large schedule slip that affects 
segment milestones or has 
possible effect on system 
milestones 
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Appendix B 


Risk Analysis Evaluation 


Table 14 - Alternative 5: Clearing House - SATCOM Enhanced Throughput 

RF = Risk Factor 

Pf^ Probability of Failure Pf^(.l*Pmhw)+(.l*Pmsw)+(.2*Pchw)+.(3*Pcsw)+(.3*Pd) 

Cf^ Consequence ofFailuCfK-5*Ct)+(.3*Cc)+(.2*Cf) 

RF - Pf + Cf -PfCf 



Probability of Failure (Pf) 

Magnitude 

Maturity Factor (Pm) 

Complexity Factor (Pc) 

Dependency Factor (Pd) 

Hardware (Pmhw) 

Software (Pmsw) 

Hardware (Pchw) 

Software (Pcsw) 

0.1 

Low 

Existing 

Existing 

Simple design 

Simple design 

Independent of existing 
system, facility or associate 
contractor 

0.3 

Minor 

Minor Redesign 

Minor redesign 

Minor increase in complexity 

Minor increase in complexity 

Schedule dependent on 
existing system, facility or 
associate contractor 

0.5 

Moderate 

Major change feasible 

Major change 

Moderate increase 

Moderate increase 

Performance dependent on 
existing system performance, 
facility or associate contractor 

0.7 

Significant 

Technology available, 
complex design 

New software, similar to 
existing 

Significant increase 

Significant increase in number 
of modules 

Schedule dependent on new 
system perfoimance, facility or 
associate contractor 

State the some research 

complete 

State of the art, never done 
before 

^^^^^^^^^^^^^^^^^HPerfonnance on 

Extremely complex system performance, 


Consequences of Failure (Cf) 

Magnitude 

Technical Factor (Ct) 

Cost Factor (Cc) 

Schedule Factor (Cs) 

O.l 

Low 

Minimal or no consequences, 
unimportant 

Budget estimates not 
exceeded, some transfer of 
money 

Negligible impact on program, 
slight development schedule 
change compensated by 
available schedule slack 

0.3 

Minor 

Small reduction in targeted 
technical performance 

Cost estimates exceeded 
budget by 1 to 5 percent 

Minor slip in schedule, some 
adjustment in milestones 
required 

0.5 

Moderate 

Some reduction in technical 
performance 

Cost estimate increased by 5 to 
20 percent 

Small slip in schedule 

0.7 

Significant 

Significant degradation in 
technical performance 

Cost estimates increased by 20 
to 50 percent 

Significant development 
schedule slip 
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Appendix B 


Risk Analysis Evaluation 


THIS PAGE INTENTIONALLY LEET BLANK 


16 



APPENDIX C Life Cycle Cost Tables 


Table 2; Baseline Calculations 







Life-Cycle Year 





Total Cost 

$K 

LAN / WAN / ISNS 

1 

$K 

2 

$K 

3 

$K 

4 

$K 

5 

$K 

6 

$K 

7 

$K 

8 

$K 

9 

$K 

10 

$K 

RDT&E (network & 
satcom) 

0 

0 

0 

0 

2,909 

0 

0 

0 

0 

0 

2,909 

OPN(SPAWAR) 

125,895 

52,876 

22,208 

9,327 

7,687 

3,229 

1,356 

570 

239 

100 

223,488 

Operation & Support 
(labor) 

696,833 

731,675 

768,259 

806,672 

847,005 

889,355 

933,823 

980,514 

1,029,540 

1,081,017 

8,764,694 

Total Cost 

822,728 

784,551 

790,467 

815,999 

857,601 

892,584 

935,179 

981,084 

1,029,779 

1,081,118 

8,991,091 


Shipboard LAN / WAN 
/ ISNS 

RDT&E 

FY08 

$K 

FY09 

$K 

FYIO 

$K 

Product development 

8,075 

4,480 

620 

Engineering support 

443 

351 

173 

T& E 

8,682 

3,367 

553 

Management 

4,485 

3,086 

422 


Baseline + 

HW Refresh 

Sites 

CJTF 

Cisco 7000 

JFMCC 

Cisco 7000 

CTF 

Cisco 3000 

HW Refresh 

cost 

$K 

HW Refresh 
Labor 

$K 

O&S Labor 
cost 

OMN 

$K 

CONUS 

17 




$136 

$163 

$39,886 

OCONUS 

11 




$88 

$106 

$25,809 

Training sites 

8 




$64 

$77 

$18,770 

NOC 


4 

4 


$1,160 

$77 

$18,770 

Force Level 




23 

$184 

$221 

$53,964 

Group Level 




84 

$672 

$806 

$197,084 

Unit Level 




75 

$600 

$720 

$175,968 

Submarines 




71 

$568 

$682 

$166,583 

Engineering & Test 

6 

1 

1 

1 

$298 

$58 


Total cost 





$3,770 

$2,909 

$696,833 
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APPENDIX C Life Cycle Cost Tables 


LAN / WAN / ISNS 


RDT&E (network & 
satcom) 

OPN(SPAWAR) 
Operation & Support 
(labor) 


Total Cost 


Table 3: Baseline Caleulations with SATCOM upgrade 


Life-Cycle Year 


Total Cost 
$K 


32,332,73( 


SATCOM 

RDT&E 


RDT&E 

OPN 


715,169 

26,336 


474,009 

91,951 


982,43< 


Total 

$K 


1,840,405 
144,477 
0 


Baseline + 
HW Refresh 


CONUS 


OCONUS 


Training sites 


NOC 


Force Levei 


Group Levei 


Unit Level 


Submarines 


Engineering & Test 


Total cost 


CJTF JFMCC CTF 

Cisco 7000 Cisco 7000 Cisco 3000 


741,5051 677,4171 565,960l 1,984,882 


O&S Labor 

HW Refresh HW Refresh cost 
cost Labor OMN 

$K $K $K 


$39,886 


$25,809 


$18,770 


$18,770 


$53,964 


$197,084 


$175,968 


$166,583 


SATCOM 

RDT&E 

$K 


135,355,734 


SATCOM OPN 

$K 


$10,582,329 

$830,743 

$38,648,505 

$3,034,017 

$34,507,594 

$2,708,944 

$32,667,189 

$2,564,467 

$460,101 

$36,119 


$696,833 


$116,865,718 


$9,174,290 














































































































APPENDIX C Life Cycle Cost Tables 



LAN / WAN / ISNS 


RDT&E (network & 
satcom) 

OPN(SPAWAR} 
Operation c£ Support 
(labor) 


Total Cost 


Table 4: DiffServ Calculations 


Life-Cycle Year 





DiffServ 


CONUS 


OCONUS 


Training sites 


NOC 


Force Levei 


Group Levei 


Unit Levei 


Submarines 


Engineering & Test 


Total cost 



CJTF JFMCC 

Cisco 7000 Cisco 7000 



$64 


$1,160 


$184 


$672 


$600 


$568 


$298 


$3,770 


HW Refresh 
Labor 

$K 

O&S Labor 
cost 

OMN 

$K 

sw 

Upgrade 

Labor 

$K 

$163 

$39,886 

$326 

$106 

$25,809 

$211 

$77 

$18,770 

$154 

$77 

$18,770 

$154 

$221 

$53,964 

$442 

$806 

$197,084 

$1,613 

$720 

$175,968 

$1,440 

$682 

$166,583 

$1,363 

$77 


$77 

$2,928 

$696,833 

$5,779 
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APPENDIX C Life Cycle Cost Tables 


Table 5: DiffServ Calculations with SATCOM upgrade 


Life-Cycle Year 


LAN / WAN / 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

Total Cost 

ISNS 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

RDT&E 
(network & 
satcom) 

29,219,322 

29,219,322 

29,216,433 

29,216,433 

2,928 

0 

0 

0 

0 

0 

116,874,437 

OPN 

2,419,467 

2,419,467 

2,419,467 

2,419,467 

25,978 

10,911 

4,583 

1,925 

808 

34C 

9,722,413 

(SPAWAR) 
Operation & 
Support 
(labor) 

696,833 

731,675 

768,259 

806,672 

847,005 

889,355 

933,823 

980,514 

1,029,540 

1,081,017 

8,764,694 

Total Cost 





875,911 






135,361,545 


DiffServ 

Sites 

CJTF 

Cisco 700( 

JFMCC 
Cisco 700( 

CTF 

Cisco 300( 

HW 

Refresh 

cost 

$K 

HW 

Refresh 

Labor 

$K 

O&S 

Labor cost 
OMN 

$K 

sw 

Upgrade 

Labor 

$K 

SATCOM 

RDT&E 

$K 

SATCOM 

OPN 

$K 

CONUS 

17 




$136 

$163 

$39,886 

$326 



OCONUS 

11 




$88 

$106 

$25,809 

$211 



Training sites 

8 




$64 

$77 

$18,770 

$154 



NOC 


4 

4 


$1,160 

$77 

$18,770 

$154 



Force Level 




23 

$184 

$221 

$53,964 

$442 

$10,582,330 

$830,743 

Group Level 




84 

$672 

$806 

$197,084 

$1,613 

$38,648,509 

$3,034,017 

Unit Level 




75 

$600 

$720 

$175,968 

$1,440 

$34,507,598 

$2,708,944 

Submarines 




71 

$568 

$682 

$166,583 

$1,363 

$32,667,192 

$2,564,467 

Engineering 6 

8 

1 

1 

1 

$298 

$77 


$77 

$460,101 

$36,119 

Total cost 





$3,770 

$2,928 

$696,833 

$5,779 

$116,865,730 

$9,174,290 
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APPENDIX C Life Cycle Cost Tables 


Table 6: MPLS Calculations 



Life-Cycle Year 

Total Cost 

LAN / WAN / ISNS 


1 



3 


4 


■ 


6 

7 



9 


10 




$K 

$K 

$K 


$K 


■ 


$K 

$K 


$K 


$K 


$K 

RDT&E (network & 
satcom) 


2,890 


2,890 


0 


c 


2,928 

0 

0 


0 


■ 


0 

8,707 

OPN(SPAWAR} 


138,795 


52,876 

22,208 

9,327 


7,687 

7,68" 

3,917 


1,645 


691 

29( 

245,125 

Operation c£ Support 


696,833 


731,675 

768,259 

806,672 



889,355 

933,823 


980,514 


1,081,017 

8,764,694 

(labor) 










1 










Total Cost 

838,518 

787,441 


815,999 

857,621| 

897,043 

937,741 


1,030,231 


9,018,527 















O&S Labor 

sw 


" 

1 












HW Refresh 

HW Refresh 

cost 


Upgrade 

MPLS 

MPLS 


Sites 


CJTF 

JFMCC 

CTF 


cost 

Labor 


OMN 


Labor 

Licenses 





Cisco 7000 

Cisco 7000 

Cisco 3000 

$K 

$K 


$K 


$K 


$k 

CONUS 

17 




$136 

$163 

$39,886 

$326 

$731 

OCONUS 

11 




$88 

$106 

$25,809 

$211 

$473 

Training sites 

8 




$64 

$77 

$18,770 

$154 

$344 

NOC 


4 

4 


$1,160 

$77 

$18,770 

$154 

$344 

Force Level 




23 

$184 

$221 

$53,964 

$442 

$989 

Group Level 




84 

$672 

$806 

$197,084 

$1,613 

$3,612 

Unit Level 




75 

$600 

$720 

$175,968 

$1,440 

$3,225 

Submarines 




71 

$568 

$682 

$166,583 

$1,363 

$3,053 

Engineering & Test 

8 

1 

1 

1 

$298 

$77 


$77 

$129 

Total cost 





$3,770 

$2,928 

$696,833 

$5,779 

$12,900 
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APPENDIX C Life Cycle Cost Tables 


Table 7: MPLS Calculations with SATCOM upgrade 



Life-Cycle Year 


LAN / WAN / 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

Total Cost 

ISNS 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

RDT&E 
(network & 
satcom) 

29,219,322 

29,219,322 

29,216,433 

29,216,433 

2,928 

0 

0 

0 

0 

0 

116,874,437 

OPN 

2,432,367 

2,419,467 

2,419,467 

2,419,467 

25,978 

10,911 

4,583 

1,925 

808 

34C 

9,735,313 

(SPAWAR) 
Operation & 
Support 
(labor) 

696,833 

731,675 

768,259 

806,672 

847,005 

889,355 

933,823 

980,514 

1,029,540 

1,081,017 

8,764,694 

Total Cost 





875,911 






135,374,445 






HW 

HW 

o&s 

sw 









Refresh 

Refresh 

Labor cost 

Upgrade 

MPLS 

SATCOM 

SATCOM 

MPLS 

Sites 

CJTF 

JFMCC 

CTF 

cost 

Labor 

OMN 

Labor 

Licenses 

RDT&E 

OPN 




BiBSBBiHii 


$K 

$K 

$K 

$K 

$k 

$K 

$K 

CONUS 

17 




$136 

$163 

$39,886 

$326 

$731 



OCONUS 

11 




$88 

$106 

$25,809 

$211 

$473 



Training sites 

8 




$64 

$77 

$18,770 

$154 

$344 



NOC 


4 

4 


$1,160 

$77 

$18,770 

$154 

$344 



Force Levei 




23 

$184 

$221 

$53,964 

$442 

$989 

$10,582,330 

$830,743 

Group Levei 




84 

$672 

$806 

$197,084 

$1,613 

$3,612 

$38,648,509 

$3,034,017 

Unit Levei 




75 

$600 

$720 

$175,968 

$1,440 

$3,225 

$34,507,598 

$2,708,944 

Submarines 




71 

$568 

$682 

$166,583 

$1,363 

$3,053 

$32,667,192 

$2,564,467 

Engineering t 

8 

1 

1 

1 

$298 

$77 


$77 

$129 

$460,101 

$36,119 

Total cost 





$3,770 

$2,928 

$696,833 

$5,779 

$12,900 

$116,865,730 

$9,174,290 
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APPENDIX C Life Cycle Cost Tables 


Table 8: Dedicated Routers Calculations 


LAN / WAN / ISNS 


Life-Cycle Year 


1 

$K 


2 

$K 


3 

$K 


4 

$K 


5 

$K 


6 

$K 


7 

$K 


$K 


9 

$K 


10 

$K 


Total Cost 
$K 


\RDT&E (network & 
satcom) 

OPN(SPAWAR} 
Operation c£ Support 
(labor) 


2,899 

128,812 

696,833 


2,899 

128,794 

731,675 


22,208 

768,259 


9,32' 

806,6721 


3,917 

847,005 


3,917 

889,355 


3,917 

933,823 


1,645 

980,514 


691 

l,029,54cl 


290 

1,081,017 


5,798 

303,521 

8,764,694 


iTotal Cost 


790,46'1 


815,99q 


893,273 


937,741 


9,074,013 


Dedicated Routers 

Sites 

CJTF 

Cisco 7000 

JFMCC 

Cisco 7000 

JFMCC 

Cisco 3000 

CTF 

Cisco 3000 

HW cost 

$K 

HW 

Upgrade 

Labor 

$K 

O&S Labor 
cost 

OMN 

$K 

CONUS 

17 





$136 

$326 

$39,886 

OCONUS 

11 





$88 

$211 

$25,809 

Training sites 

8 





$64 

$154 

$18,770 

NOC 


4 

4 

4 


$1,192 

$154 

$18,770 

Force Levei 





23 

$368 

$442 

$53,964 

Group Levei 





84 

$1,344 

$1,613 

$197,084 

Unit Levei 





75 

$1,200 

$1,440 

$175,968 

Submarines 





71 

$1,136 

$1,363 

$166,583 

Engineering & Test 

10 

1 

1 

1 

1 

$306 

$96 


Total cost 






$5,834 

$5,798 

$696,833 
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APPENDIX C Life Cycle Cost Tables 


Table 9: Dedicated Routers Calculations with SATCOM upgrade 


Life-Cycle Year 


LAN / WAN / 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

Total Cost 

ISNS 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

RDT&E 
(network & 
satcom) 

29,217,925 

29,217,925 

29,216,433 

29,216,433 

2,986 

0 

C 

C 

0 

0 

116,871,701 

OPN 

2,419,467 

2,419,467 

2,419,467 

2,419,467 


11,778 

4,947 

2,078 

873 

366 

9,725,952 

(SPAWAR) 
Operation & 
Support 
(labor) 

696,833 

731,675 

768,259 

806,672 

847,005 

889,355 

933,823 

980,514 

1,029,540 

1,081,017 

8,764,694 

Total Cost 

32,334,226 




878,033 

901,133 

938,770 

982,592 

1,030,413 

1,081,384 

135,362,348 


Dedicated 

Routers 

Sites 

CJTF 

Cisco 7000 

JFMCC 
Cisco 7000 

JFMCC 
Cisco 3000 

CTF 

Cisco 3000 

HW 

Refresh 

cost 

$K 

HW 

Refresh 

Labor 

$K 

o&s 

Labor cost 
OMN 

$K 

SATCOM 

RDT&E 

$K 

SATCOM 

OPN 

$K 

CONUS 

17 





$136 

$163 

$39,886 



OCONUS 

11 





$88 

$106 

$25,809 



Training sites 

8 





$64 

$77 

$18,770 



NOC 


4 

4 

4 


$1,192 

$115 

$18,770 



Force Levei 





23 

$368 

$221 

$53,964 

$10,582,330 

$830,743 

Group Levei 





84 

$1,344 

$806 

$197,084 

$38,648,509 

$3,034,017 

Unit Levei 





75 

$1,200 

$720 

$175,968 

$34,507,598 

$2,708,944 

Submarines 





71 

$1,136 

$682 

$166,583 

$32,667,192 

$2,564,467 

Engineering 6 

10 

1 

1 

1 

1 

$306 

$96 


$460,101 

$36,119 

Total cost 






$5,834 

$2,986 

$696,833 

$116,865,730 

$9,174,290 
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APPENDIX C Life Cycle Cost Tables 


Table 10: Routers Upgrade Calculations 



Life-Cycle Year 

Total Cost 

LAN / WAN / ISNS 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 


$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

RDT&E (network & 
satcom) 

2,909 

c 

c 

c 

c 

c 

c 

c 

c 

c 

2,909 

OPN(SPAWAR) 

169,395 

71,14^ 


9,327 

3,917 

1,645 

3,917 

1,645 

691 

290 

284,183 

Operation & Support 
(labor) 

696,833 

731,675 

768,259 

806,672 


889,355 

933,823 

980,51^ 

1,029,540 

1,081,017 

8,764,694 

Total Cost 

869,137 

802,821 



850,923 

891,001 

937,741 


1,030,231 


9,051,786 


Routers Upgrade 

Sites 

CJTF 

Cisco 7000 


CTF 

Cisco 7000 

HW cost 

$K 

HW Refresh 
Labor 

$K 

o&s 

Labor cost 
OMN 

$K 

CONUS 

17 




$2,465 

$163 

$39,886 

OCONUS 

11 




$1,595 

$106 

$25,809 

Training sites 

8 




$1,160 

$77 

$18,770 

NOC 


4 

4 


$1,160 

$77 

$18,770 

Force Levei 




23 

$3,335 

$221 

$53,964 

Group Levei 




84 

$12,180 

$806 

$197,084 

Unit Levei 




75 

$10,875 

$720 

$175,968 

Submarines 




71 

$10,295 

$682 

$166,583 

Engineering & Test 

6 

1 

1 

1 

$435 

$58 


Total cost 





$43,500 

$2,909 

$696,833 


11 























































































APPENDIX C Life Cycle Cost Tables 


Table 11: Routers Upgrade Calculations with SATCOM upgrade 



1 Life-Cycle Year | 


LAN / WAN / 

1 

2 

3 

4 

5 

6 

7 

8 


9 


10 

Total Cost 

ISNS 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 


$K 


$K 

$K 

RDT&E 
(network & 
satcom) 

29,219,341 

29,216,433 

29,216,433 


0 

0 

0 


0 


0 

0 

116,868,639 

OPN 

2,462,967 

2,419,467 

2,419,467 

2,419,467 

1,016,176 

426,794 

mEm 

426,794 

179,253 

75,286 

mmm 

(SPA WAR) 














Operation & 

696,833 

731,675 

768,259 

806,672 


889,355 

933,823 

980,514 

1,029,540 

1,081,017 

8,764,694 

Support 

(labor) 














Total Cost 


32,367,575 




1,316,150 

1,950,000 




138,495,183 








HW 

o&s 







Routers 






Refresh 

Labor cost 

SATCOM 





Upgrade 

Sites 

CJTF 

JFMCC 

CTF 

HW cost 

Labor 

OMN 

RDT&E 

SATCOM OPN 





[iUSBBBiHii 

[iiHSBBiHii 

[iUSBBBiHii 

$K 

$K 

$K 


$K 


$K 



CONUS 

17 




$2,465 

$163 

$39,886 





OCONUS 

11 




$1,595 

$106 

$25,809 





Training sites 

8 




$1,160 

$77 

$18,770 





NOC 


4 

4 


$1,160 

$77 

$18,770 





Force Level 




23 

$3,335 

$221 

$53,964 

$10,582,330 

$830,743 



Group Level 




84 

$12,180 

$806 

$197,084 

$38,648,509 

$3,034,017 



Unit Level 




75 

$10,875 

$720 

$175,968 

$34,507,598 

$2,708,944 



Submarines 




71 

$10,295 

$682 

$166,583 

$32,667,192 

$2,564,467 



Engineering 6 

6 

1 

1 

1 

$435 

$58 


$460,101 

$36,119 



Total cost 





$43,500 

$2,909 

$696,833 

$116,865,730 

$9,174,290 
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APPENDIX C Life Cycle Cost Tables 


Table 12: Routers Upgrade & MPLS Implementation Calculations 


Life-Cycle Year 


LAN / WAN / ISNS 

1 

$K 

2 

$K 

3 

$K 

4 

$K 

5 

$K 

6 

$K 

7 

$K 

8 

$K 

9 

$K 

10 

$K 

Total Cost 

$K 

RDT&E (network cfe 
satcom) 

5,798 

0 

0 

0 

0 

0 

( 

0 

( 

0 

5,798 

OPN(SPAWAR) 


154,095 


9,327 

3,917 

1,645 

3,917 

1,645 

691 

290 

351,832 

Operation & Support 
(labor) 

696,833 

731,675 

768,259 

806,672 

847,005 

889,355 

933,823 

980,514 

1,029,540 

1,081,017 

8,764,694 

Total Cost 


885,770 




891,001 

937,741 


1,030,231 


9,122,325 


Router Upgrade & 
MPLS 

Sites 

CJTF 

Cisco 7000 

JFMCC 

Cisco 7000 

CTF 

Cisco 7000 

HW cost 

$K 

SW/HW 

Upgrade 

Labor 

$K 

O&S 

Labor cost 
OMN 

$K 

MPLS 

Licenses 

$k 

CONUS 

17 




$2,465 

$326 

$39,886 

$731 

OCONUS 

11 




$1,595 

$211 

$25,809 

$473 

Training sites 

8 




$1,160 

$154 

$18,770 

$344 

NOC 


4 

4 


$1,160 

$154 

$18,770 

$344 

Force Levei 




23 

$3,335 

$442 

$53,964 

$989 

Group Levei 




84 

$12,180 

$1,613 

$197,084 

$3,612 

Unit Levei 




75 

$10,875 

$1,440 

$175,968 

$3,225 

Submarines 




71 

$10,295 

$1,363 

$166,583 

$3,053 

Engineering & Test 

10 

1 

1 

1 

$435 

$96 


$129 

Total cost 





$43,500 

$5,798 

$696,833 

$12,900 
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APPENDIX C Life Cycle Cost Tables 


Table 13: Routers Upgrade & MPLS Implementation Calculations with SATCOM upgrade 



Life-Cycle Year 


LAN / WAN / 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

Total Cost 

ISNS 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

RDT&E 
(network & 
satcom) 

29,222,231 

29,216,433 

29,216,433 

29,216,433 

0 

0 

0 

0 

0 

0 

116,871,529 

OPN 

2,447,667 

2,447,667 

2,419,467 

2,419,467 

mmm 

426,794 

■EH 

426,794 

179,253 

75,286 


(SPAWAR) 
Operation & 
Support 
(labor) 

696,833 

731,675 

768,259 

806,672 

847,005 

889,355 

933,823 

980,514 

1,029,540 

1,081,017 

8,764,694 

Total Cost 







1,950,000 


1,208,794 

1,156,304 

138,510,973 


Router 
Upgrade & 
MPLS 

Sites 

CJTF 

Cisco 700( 

JFMCC 
Cisco 700( 

CTF 

Cisco 700( 

HW cost 

$K 

SW/HW 

Upgrade 

Labor 

$K 

O&S 

Labor cost 
OMN 

$K 

MPLS 

Licenses 

$k 

CONUS 

17 




$2,465 

$326 

$39,886 

$731 

OCONUS 

11 




$1,595 

$211 

$25,809 

$473 

Training sites 

8 




$1,160 

$154 

$18,770 

$344 

NOC 


4 

4 


$1,160 

$154 

$18,770 

$344 

Force Levei 




23 

$3,335 

$442 

$53,964 

$989 

Group Levei 




84 

$12,180 

$1,613 

$197,084 

$3,612 

Unit Levei 




75 

$10,875 

$1,440 

$175,968 

$3,225 

Submarines 




71 

$10,295 

$1,363 

$166,583 

$3,053 

Engineering 6 

10 

1 

1 

1 

$435 

$96 


$129 

Total cost 





$43,500 

$5,798 

$696,833 

$12,900 
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APPENDIX C Life Cycle Cost Tables 


Table 14: Priority Queuing Calculations 


1- 


Life-Cycle Year 



LAN/WAN/ISNS 

1 

2 


3 


4 



6 


7 


8 

9 


10 



_ 


$K 

$K 


$K 


$K 

__ 

$K 


$K 


$K 

$K 


$K 


$K 

\RDT&E (network & 

3,024 



C 




2,909 


c 


H 

c 

c 

1 



5,933 

\satcom) 
















1 




OPN(SPAWAR) 






9,327 


7,687 


3,229 

1,35^ 

570 

239 

1 



223,488 

Operation & Support 






424,994 


446,244 

468,556 

491,984 

516,583 

542,412 

1 



4,947,378 

\(labor) 
















1 




|Total Cost 

825,752 

438,358 

426,964 

434,321 

456,840 

471,785 

493,340 

517,153 

542,651 

569,633 

5,176,798 
















o&s 


sw 














HW Refresh 

HW Refresh 

Labor cost 


Upgrade 




Priority Queuing 

Sites 


CJTF 


JFMCC 

CTF 


cost 


Labor 

OMN 


Labor 








Cisco 7000 

Cisco 7000 

Cisco 3000 


$K 


$K 

$K 


$K 




CONUS 

17 




$136 

$163 

$22,065 

$163 



OCONUS 

11 




$88 

$106 

$14,277 

$106 



Training sites 

8 




$64 

$77 

$10,383 

$77 



NOC 


4 

4 


$1,160 

$77 

$10,383 

$77 



Force Levei 




23 

$184 

$221 

$29,852 

$221 



Group Levei 




84 

$672 

$806 

$109,025 

$806 



Unit Levei 




75 

$600 

$720 

$97,344 

$720 



Submarines 




71 

$568 

$682 

$92,152 

$682 



Engineering & Test 

18 

1 

1 

1 

$298 

$58 


$173 



Total cost 





$3,770 

$2,909 

$385,482 

$3,024 
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APPENDIX C Life Cycle Cost Tables 


Table 15: Priority Queuing Calculations with SATCOM upgrade 



Life-Cycle Year 


LAN / WAN / 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

Total Cost 

ISNS 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

$K 

RDT&E 
(network & 
satcom) 

29,219,457 

29,216,433 

■ 

29,216,433 

2,909 

0 

0 

0 

0 

0 

116,871,663 

OPN 

2,419,467 

2,419,467 

2,419,467 

2,419,467 

56,646 

23,791 

9,992 

4,197 

1,763 

74C 

9,774,999 

(SPAWAR) 
Operation & 
Support 
(labor) 

696,833 

385,482 

404,756 

424,994 

446,244 

468,556 

491,984 

516,583 

542,412 

569,533 

4,947,378 

Total Cost 







501,976 

520,780 



131,594,040 


Priority 

Queuing 

Sites 

CJTF 

Cisco 700( 

JFMCC 
Cisco 700( 

CTF 

Cisco 300( 

HW 

Refresh 

cost 

$K 

HW 

Refresh 

Labor 

$K 

O&S 

Labor cost 
OMN 

$K 

sw 

Upgrade 

Labor 

$K 

CONUS 

17 




$136 

$163 

$22,065 

$163 

OCONUS 

11 




$88 

$106 

$14,277 

$106 

Training sites 

8 




$64 

$77 

$10,383 

$77 

NOC 


4 

4 


$1,160 

$77 

$10,383 

$77 

Force Levei 




23 

$184 

$221 

$29,852 

$221 

Group Levei 




84 

$672 

$806 

$109,025 

$806 

Unit Levei 




75 

$600 

$720 

$97,344 

$720 

Submarines 




71 

$568 

$682 

$92,152 

$682 

Engineering 6 

18 

1 

1 

1 

$298 

$58 


$173 

Total cost 





$3,770 

$2,909 

$385,482 

$3,024 
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APPENDIX C: Life Cycle Cost Tables 


Notes: 

• RDT&E and OPN (SPAWAR) data is based on the budget exhibits for ISNS, 

SCI and CENTRIXS. 060423 IN Tactical Command System, Exhibit R-2a, 
RDT&E Budget Item Justification, May 2009, pages 59-65 

• ISNS is expecting 58% budget cut for EY11, so it's assumed the same budget cut 
for the future years. 

• SATCOM cost for Advanced Extremely High Erequency (AEHE) and Mobile 
User Objective System (MUOS). 0303109N Satellite Communications, Exhibit 
R-2, RDT&E Budget Item Justification, May 2009, page 1 

• O&S Eabor is calculated based on average hourly cost of $120 per hour; there are 
5 personnel at each site, 4 watch-standers at 12/7/365 and one maintenance during 
day. email from Robert Sotelo, Nov 18, 2010 

• The number of routers is calculated based on the EYIO Navy GCCS Eorce 
Structure. 

• Eabor for DiftBerv and MPES implementation is estimated at 8 weeks of 
engineering and test plus 2 weeks of deployment per site per alternative 
implementation. 

• MPLS License cost is based on commercial cost of MPLS Management Consol 
cost of $43k for each router. 

• Cisco 7000 series routers are estimated at $145k each. 

• Cisco 3000 series routers are estimated at $8k each. 

• Baseline HW Refresh labor is calculated based on average hourly cost of $4800 
per week, per person for a team of two installers for 1 week per router installed 
plus 6 weeks of engineering and test and the cost of routers for the lab. 

• Table 1 shows the time requirements per implementation. 
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APPENDIX C Life Cycle Cost Tables 


Table 1: Alternatives implementation labor cost estimation 



Engineering 

Test 

Deployment 

Cost 

Alternative 

(weeks) 

(weeks) 

(weeks) 

($k) 

Baseline Hardware Refresh 

2 

2 

2 

54 

Router Upgrade 

2 

4 

3 

81 

DiffServ 

4 

4 

10 

161 

MPLS 

4 

4 

10 

161 

Dedicated C2 Routers 

6 

4 

10 

179 

MPLS + Router Upgrade 

4 

6 

3 

116 

Priority Queues 

8 

10 

4 

197 
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APPENDIX D DATA ANALYSIS OF FUNCTIONAL MODEL 


A, Results for Run 1; CJTF Functions Timing 

Table 2-1 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function executes as 
soon as it’s activated in the model. The total time to execute these functions form a baseline for 
comparison with simulation runs that will demonstrate synchronization of functions with data to 
demonstrate Command and Control cycle time. 


Table 1 - Time to Complete CJTF Functions 


Model Summary 

This model simulates a data only scenario (all functions 
execute as soon as activated) with the CJTF 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP CJTF ( 

'data only) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

11/09 

16:15 

7784.74 

21 

11/09 

16:24 

7863.3 

2 

11/09 

16:15 

7710.91 

22 

11/09 

16:25 

7777.64 

3 

11/09 

16:16 

7797.3 

23 

11/09 

16:25 

7820.73 

4 

11/09 

16:16 

7777.5 

24 

11/09 

16:26 

7747.31 

5 

11/09 

16:17 

7811.4 

25 

11/09 

16:26 

7774.04 

6 

11/09 

16:17 

7751.45 

26 

11/09 

16:27 

7784.35 

7 

11/09 

16:18 

7747.67 

27 

11/09 

16:27 

7793.69 

8 

11/09 

16:18 

7804.75 

28 

11/09 

16:28 

7750.53 

9 

11/09 

16:19 

7756.60 

29 

11/09 

16:28 

7793.96 

10 

11/09 

16:19 

7753.67 

30 

11/09 

16:29 

7724.19 

11 

11/09 

16:20 

7755.75 

31 

11/09 

16:29 

7809.79 

12 

11/09 

16:20 

7777.64 

32 

11/09 

16:30 

7794.76 

13 

11/09 

16:21 

7752.84 

33 

11/09 

16:30 

7777.06 

14 

11/09 

16:21 

7785.04 

34 

11/09 

16:31 

7747.57 

15 

11/09 

16:22 

7788.03 

35 

11/09 

16:31 

7816.31 

16 

11/09 

16:22 

7733.93 

36 

11/09 

16:32 

7815.77 

17 

11/09 

16:23 

7723.58 

37 

11/09 

16:32 

7819.96 

18 

11/09 

16:23 

7766.76 

38 

11/09 

16:33 

7770.97 

19 

11/09 

16:23 

7775.78 

39 

11/09 

16:33 

7745.55 

20 

11/09 

16:24 

7760.97 

40 

11/09 

16:34 

7793.86 




APPENDIX D DATA ANALYSIS OF FUNCTIONAL MODEL 


1 


Table 2 provides statistics calculated (using Microsoft Excel) from the sample data in run 


Table 2 - Run 1 Statistics 



Statistic 

Value 

1 

Minimum 

7710.91 

2 

Maximum 

7863.30 

3 

Range 

152.39 

4 

Average 

7775.94 

5 

Std Dev 

31.3528635 

6 

Conf90% 

8.15407071 

7 

conf 80% 

6.35306505 

8 

Variance 

983.002052 
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APPENDIX D DATA ANALYSIS OF FUNCTIONAL MODEL 


B. Results for Run 2; CJTF (Synchronized with Data Triggers) 

Table 3 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 3 - Time to Complete CJTF and JFMCC Cycles (Data & Synchronization) 


Model Summary 

This model simulates a synchronous data scenario 
between within a CJTF. Functions within the CJTF must 
wait for triggering data to be received before proceeding. 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP CJTF ( 

'with trig) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

11/09 

15:10 

7783.66 

21 

11/09 

15:48 

7825.88 

2 

11/09 

15:15 

7809.89 

22 

11/09 

15:49 

7772.17 

3 

11/09 

15:18 

7816.2 

23 

11/09 

15:50 

7788.97 

4 

11/09 

15:20 

7810.63 

24 

11/09 

15:51 

7780.12 

5 

11/09 

15:21 

7810.32 

25 

11/09 

15:52 

7791.91 

6 

11/09 

15:23 

7790.73 

26 

11/09 

15:53 

7802.73 

7 

11/09 

15:24 

7794.2 

27 

11/09 

15:54 

7814.86 

8 

11/09 

15:25 

7836.38 

28 

11/09 

15:56 

7800.17 

9 

11/09 

15:26 

7814.72 

29 

11/09 

15:57 

7830.66 

10 

11/09 

15:27 

7775.59 

30 

11/09 

15:58 

7807.18 

11 

11/09 

15:29 

7821.37 

31 

11/09 

15:59 

7808.47 

12 

11/09 

15:30 

7763.98 

32 

11/09 

16:00 

7810.88 

13 

11/09 

15:32 

7757.89 

33 

11/09 

16:01 

7808.16 

14 

11/09 

15:33 

7807.73 

34 

11/09 

16:02 

7764.42 

15 

11/09 

15:34 

7766.84 

35 

11/09 

16:04 

7792.24 

16 

11/09 

15:42 

7801.6 

36 

11/09 

16:05 

7782.24 

17 

11/09 

15:43 

7798.79 

37 

11/09 

16:07 

7808.58 

18 

11/09 

15:45 

7810.9 

38 

11/09 

16:08 

7833.24 

19 

11/09 

15:46 

7815.21 

39 

11/09 

16:09 

7804.36 

20 

11/09 

15:47 

7806.1 

40 

11/09 

16:10 

7800.02 
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APPENDIX D DATA ANALYSIS OF FUNCTIONAL MODEL 


Table 4 provides statistics calculated (using Microsoft Excel) from the sample data in run 


2 


Table 4 - Run 2 Statistics 



Statistic 

Value 

1 

Minimum 

7757.89 

2 

Maximum 

7836.38 

3 

Range 

78.49 

4 

Average 

7800.50 

5 

Std Dev 

19.2904583 

6 

Conf90% 

5.0169504 

7 

conf 80% 

3.90884668 

8 

Variance 

372.121782 


Once the data was collected to determine the day introduced by synchronizing functions 
in the CJTF Command and Control Cycle, a preliminary test for the equality of variances 
indicates that the variances of the two groups were different. Table 5 shows the results of F- 
Test from Excel Data Analysis tools on both data samples Since the results for P(F<=f) is < 
0.05; it is assumed that the variances are from different distributions and a T-Test for Non Equal 
Means would be appropriate. 


Table 5 - Results for F-Test for Run 1 and Run 2 Data 


F-Test Two-Sample for Variances 


Variable 1 

Variable 2 


Variable 3 

Variable 4 

Mean 

7775.941 

7856.187 

Mean 

7936.432 

8016.677 

Variance 

983.0021 

515.9039 

Variance 

48.80569 

-418.292 

Observations 

40 

40 

Observations 

40 

40 

df 

39 

39 

df 

39 

39 

F 

1.905398 


F 

1.905398 


P(F<=f) one-tail 

0.023663 


P(F<=f) one-tail 

0.023663 


F Critical one-tail 

1.704465 


F Critical one- 
tail 

1.704465 



A T-Test for Non-Equal variances was performed using Excel Data Analysis 
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APPENDIX D DATA ANALYSIS OF FUNCTIONAL MODEL 


tools on both data samples. The results are shown in Table TBS.X. Since the value of 
P(T<=t) is les than 0.05, this is evidence that these two samples are statistically 
different (providing evidence to reject the null hypothesis of equal means.) 


Table 6 - Results of T-Test for Run 1 and Run 2 Data 



Variable 1 

Variable 2 


Mean 

7775.94125 

7856.1865 

Mean 

Variance 

983.0020523 

515.9038695 

Variance 

Observations 

40 

40 

Observations 

Hypothesized Mean 
Difference 

0 


Hypothesized Mean 

Difference 

df 

71 


df 

t Stat 

-13.108776 


t Stat 

P(T<=t) one-tail 

6.12671E-21 


P(T<=t) one-tail 

t Critical one-tail 

1.666599659 


t Critical one-tail 

P(T<=t) two-tail 

1.22534E-2d 


P(T<=t) two-tail 

t Critical two-tail 

1.993943341 


t Critical two-tail 
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C. Results for Run 3; CJTF and JFMCC Functions Timing 

Table 7 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function executes as 
soon as it’s activated in the model. The total time to execute these functions form a baseline for 
comparison with simulation runs that will demonstrate synchronization of functions with data to 
demonstrate Command and Control cycle time. 


Table 7 - Time to Complete CJTF & JFMCC Functions 


Model Summary 

This model simulates a data only scenario (all function 
execute as soon as activated) with the CJTF and 

JFMCC 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP CJTF & JFMCC (data Only) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 


18:01 

7810.85 

21 


18:16 

7790.58 

2 


18:01 

7802.28 

22 


18:17 

7809.93 

3 


18:02 

7795.97 

23 


18:17 

7764.02 

4 


18:02 

7791.81 

24 


18:18 

7790.86 

5 


18:03 

7804.82 

25 


18:19 

7854.66 

6 


18:04 

7776.69 

26 


18:20 

7767.42 

7 


18:05 

7778.25 

27 


18:21 

7749.04 

8 


18:05 

7801.2 

28 


18:21 

7827.52 

9 


18:06 

7794.04 

29 


18:22 

7811.85 

10 


18:07 

7826.93 

30 


18:23 

7780.24 

11 


18:08 

7784.19 

31 


18:24 

7704.54 

12 


18:09 

7794.69 

32 


18:25 

7788.21 

13 


18:10 

7767.17 

33 


18:25 

7792.52 

14 


18:10 

7818.37 

34 


18:26 

7759.22 

15 


18:11 

7768.96 

35 


18:26 

7791.05 

16 


18:12 

7789.35 

36 


18:27 

7794.21 

17 


18:12 

7792.96 

37 


18:28 

7798.34 

18 


18:13 

7788.86 

38 


18:29 

7797.58 

19 


18:14 

7802.06 

39 


18:30 

7787.68 

20 


18:15 

7759.72 

40 


18:30 

7805.87 
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Table 8 provides statistics calculated (using Microsoft Excel) from the sample data in run 


3 


Table 8 - Run 3 Statistics 



Statistic 

Value 

1 

Minimum 

7704.54 

2 

Maximum 

7854.66 

3 

Range 

150.12 

4 

Average 

7790.36 

5 

Std Dev 

24.6215119 

6 

Conf90% 

6.40341985 

7 

conf 80% 

4.98908389 

8 

Variance 

606.218846 
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D, Results for Run 4; CJTF, JFMCC (Synchronized with Data Triggers) 

Table 9 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 9 - Time to Complete CJTF, and JFMCC Cycles (Data & Synchronization) 


Model Summary 

This model simulates a synchronous data scenario 
between within a CJTF and JFMCC. Functions within 
the CJTF and JFMCC must wait for triggering data to be 
received before proceeding. 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP CJTF & JFMCC ( 

'with trig) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 


19:30 

11886.59 

21 


19:49 

11875.3 

2 


19:30 

11909.47 

22 


19:50 

11816.12 

3 


19:31 

11869.97 

23 


19:51 

11885.91 

4 


19:32 

11844.63 

24 


19:52 

11849.53 

5 


19:33 

11886.44 

25 


19:53 

11861.49 

6 


19:34 

11900.84 

26 


19:54 

11886.35 

7 


19:35 

11856.99 

27 


19:55 

11830.96 

8 


19:36 

11876.61 

28 


19:56 

11797.43 

9 


19:37 

11822.57 

29 


19:58 

11876.84 

10 


19:38 

11830.48 

30 


19:58 

11851.89 

11 


19:39 

11878.05 

31 


19:59 

11917.63 

12 


19:40 

11894.37 

32 


20:00 

11814.1 

13 


19:41 

11832.43 

33 


20:01 

11875.55 

14 


19:42 

11857.42 

34 


20:02 

11866.6 

15 


19:44 

11861.6 

35 


20:03 

11900.46 

16 


19:45 

11783.37 

36 


20:04 

11875.8 

17 


19:45 

11844.79 

37 


20:05 

11910.07 

18 


19:46 

11811.08 

38 


20:07 

11799.4 

19 


19:47 

11797.72 

39 


20:08 

11872.66 

20 


19:48 

11792.95 

40 


20:09 

11769.32 


Table 10 provides statistics calculated (using Microsoft Excel) from the sample data in 

run 4 
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Table 10 - Run 4 Statistics 



Statistic 

Value 

1 

Minimum 

11769.32 

2 

Maximum 

11917.63 

3 

Range 

148.31 

4 

Average 

11854.29 

5 

Std Dev 

38.2860547 

6 

Conf90% 

9.95721481 

7 

eonf 80% 

7.75794516 

8 

Varianee 

1465.82198 
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E. Results for Run 5; CJTF, JFMCC, and CTF One Functions Timing 

Table 11 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function executes as 
soon as it’s activated in the model. The total time to execute these functions form a baseline for 
comparison with simulation runs that will demonstrate synchronization of functions with data to 
demonstrate Command and Control cycle time. 


Table 11 - Time to Complete CJTF, JFMCC, and CTF One Functions 


Model Summary 

This model simulates a data only scenario (all function 
execute as soon as activated) with the CJTF and JFMCC 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP 1 CTF (data) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

31-Oct 

15:10 

7783.66 

21 

31-Oct 

15:48 

7825.88 

2 

31-Oct 

15:15 

7809.89 

22 

31-Oct 

15:49 

7772.17 

3 

31-Oct 

15:18 

7816.2 

23 

31-Oct 

15:50 

7788.97 

4 

31-Oct 

15:20 

7810.63 

24 

31-Oct 

15:51 

7780.12 

5 

31-Oct 

15:21 

7810.32 

25 

31-Oct 

15:52 

7791.91 

6 

31-Oct 

15:23 

7790.73 

26 

31-Oct 

15:53 

7802.73 

7 

31-Oct 

15:24 

7794.2 

27 

31-Oct 

15:54 

7814.86 

8 

31-Oct 

15:25 

7836.38 

28 

31-Oct 

15:56 

7800.17 

9 

31-Oct 

15:26 

7814.72 

29 

31-Oct 

15:57 

7830.66 

10 

31-Oct 

15:27 

7775.59 

30 

31-Oct 

15:58 

7807.18 

11 

31-Oct 

15:29 

7821.37 

31 

31-Oct 

15:59 

7808.47 

12 

31-Oct 

15:30 

7763.98 

32 

31-Oct 

16:00 

7810.88 

13 

31-Oct 

15:32 

7757.89 

33 

31-Oct 

16:01 

7808.16 

14 

31-Oct 

15:33 

7807.73 

34 

31-Oct 

16:02 

7764.42 

15 

31-Oct 

15:34 

7766.84 

35 

31-Oct 

16:04 

7792.24 

16 

31-Oct 

15:42 

7801.6 

36 

31-Oct 

16:05 

7782.24 

17 

31-Oct 

15:43 

7798.79 

37 

31-Oct 

16:07 

7808.58 

18 

31-Oct 

15:45 

7810.9 

38 

31-Oct 

16:08 

7833.24 

19 

31-Oct 

15:46 

7815.21 

39 

31-Oct 

16:09 

7804.36 

20 

31-Oct 

15:47 

7806.1 

40 

31-Oct 

16:10 

7800.02 
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Table 12 provides statisties calculated (using Microsoft Excel) from the sample data in 

run 5 


Table 12 - Run 5 Statistics 



Statistic 

Value 

1 

Minimum 

7757.89 

2 

Maximum 

7836.38 

3 

Range 

78.49 

4 

Average 

7800.50 

5 

Std Dev 

19.2904583 

6 

Conf90% 

5.0169504 

7 

conf 80% 

3.90884668 

8 

Variance 

372.121782 
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F, Results for Run 6; CJTF, JFMCC, and CTF One (Synchronized with Data Triggers) 

Table 13 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 13 - Time to Complete CJTF, JFMCC, and CTF One Cycles (Data & 
Synchronization) 


Model Summary 

This model simulates a synchronous data scenario within 
a CJTF, JFMCC, and CTF One. Functions within the 
CJTF, JFMCC, and CTF One must wait for triggering 
data to be received before proceeding. 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP 1 CTF (with trig) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

31-Oct 

11:30 

16391.50 

21 

31-Oct 

12:06 

16500.69 

2 

31-Oct 

11:32 

16417.66 

22 

31-Oct 

12:08 

16489.03 

3 

31-Oct 

11:34 

16407.99 

23 

31-Oct 

12:09 

16422.41 

4 

31-Oct 

11:36 

16406.75 

24 

31-Oct 

12:13 

16316.29 

5 

31-Oct 

11:37 

16461.78 

25 

31-Oct 

12:14 

16427.83 

6 

31-Oct 

11:38 

16392.76 

26 

31-Oct 

12:16 

16456.13 

7 

31-Oct 

11:41 

16501.92 

27 

31-Oct 

12:17 

16366.58 

8 

31-Oct 

11:42 

16367.92 

28 

31-Oct 

12:19 

16389.86 

9 

31-Oct 

11:45 

16375.27 

29 

31-Oct 

12:20 

16420 

10 

31-Oct 

11:46 

16370.63 

30 

31-Oct 

12:22 

16459.32 

11 

31-Oct 

11:49 

16415.46 

31 

31-Oct 

12:23 

16412.58 

12 

31-Oct 

11:50 

16361.57 

32 

31-Oct 

12:25 

16381.77 

13 

31-Oct 

11:52 

16409.25 

33 

31-Oct 

12:26 

16439.2 

14 

31-Oct 

11:54 

16449.92 

34 

31-Oct 

12:28 

16449.25 

15 

31-Oct 

11:56 

16391.58 

35 

31-Oct 

12:29 

16371.76 

16 

31-Oct 

11:58 

16490.81 

36 

31-Oct 

12:31 

16318.25 

17 

31-Oct 

12:00 

16413.74 

37 

31-Oct 

12:32 

16362.79 

18 

31-Oct 

12:02 

16409.76 

38 

31-Oct 

12:34 

16356.29 

19 

31-Oct 

12:04 

16456.9 

39 

31-Oct 

12:36 

16433.9 

20 

31-Oct 

12:05 

16367.83 

40 

31-Oct 

12:37 

16375.18 
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Table 14 provides statisties calculated (using Microsoft Excel) from the sample data 


run 6 


Table 14 - Run 6 Statistics 



Statistic 

Value 

1 

Minimum 

16316.29 

2 

Maximum 

16501.92 

3 

Range 

185.63 

4 

Average 

16410.25 

5 

Std Dev 

45.8112346 

6 

Conf90% 

11.9143199 

7 

conf 80% 

9.2827806 

8 

Variance 

2098.66922 


G. 


Results for Run 7; CJTF, JFMCC, CTF One, and CTF Two Functions Timing 
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Table 15 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function executes as 
soon as it’s activated in the model. The total time to execute these functions form a baseline for 
comparison with simulation runs that will demonstrate synchronization of functions with data to 
demonstrate Command and Control cycle time. 


Table 16 - Time to Complete CJTF, JFMCC, CTF One, and CTF Two Functions 


Model Summary 

This model simulates a data only scenario (all function 
execute as soon as activated) with the CJTF, JFMCC, CTF 
One, and CTF Two 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP 2 CTF (data) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

15-Nov 

20:08 

7856.16 

21 

15-Nov 

20:39 

7889.74 

2 

15-Nov 

20:11 

7886.13 

22 

15-Nov 

20:40 

7857.77 

3 

15-Nov 

20:13 

7861.59 

23 

15-Nov 

20:42 

7859.77 

4 

15-Nov 

20:14 

7867.02 

24 

15-Nov 

20:43 

7880.47 

5 

15-Nov 

20:15 

7853.72 

25 

15-Nov 

20:44 

7854.9 

6 

15-Nov 

20:17 

7897.58 

26 

15-Nov 

20:46 

7922.51 

7 

15-Nov 

20:18 

7892.48 

27 

15-Nov 

20:48 

7888.33 

8 

15-Nov 

20:19 

7855.23 

28 

15-Nov 

20:49 

7869.48 

9 

15-Nov 

20:20 

7848.54 

29 

15-Nov 

20:50 

7853.26 

10 

15-Nov 

20:22 

7830.98 

30 

15-Nov 

20:52 

7845.04 

11 

15-Nov 

20:24 

7859.9 

31 

15-Nov 

20:54 

7880.87 

12 

15-Nov 

20:25 

7855.82 

32 

15-Nov 

20:55 

7837.31 

13 

15-Nov 

20:27 

7881.84 

33 

15-Nov 

20:57 

7868.58 

14 

15-Nov 

20:28 

7839.48 

34 

15-Nov 

20:58 

7837.61 

15 

15-Nov 

20:29 

7850.57 

35 

15-Nov 

21:00 

7851.23 

16 

15-Nov 

20:31 

7842.91 

36 

15-Nov 

21:01 

7859.24 

17 

15-Nov 

20:32 

7839.25 

37 

15-Nov 

21:03 

7878.17 

18 

15-Nov 

20:34 

7877.26 

38 

15-Nov 

21:04 

7869.53 

19 

15-Nov 

20:35 

7872.41 

39 

15-Nov 

21:06 

7875.69 

20 

15-Nov 

20:37 

7872.31 

40 

15-Nov 

21:07 

7915.5 


Table 17 provides statistics calculated (using Microsoft Excel) from the sample data in 

run 7 
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Table 17 - Run 7 Statistics 



Statistic 

Value 

1 

Minimum 

7830.98 

2 

Maximum 

7922.51 

3 

Range 

91.53 

4 

Average 

7865.90 

5 

Std Dev 

20.8426109 

6 

Conf90% 

5.42062524 

7 

eonf 80% 

4.22336106 

8 

Varianee 

434.414431 
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H. Results for Run 8; CJTF, JFMCC, CTF One, and CTF Two (Synchronized with Data 
Triggers) 

Table 18 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 18 - Time to Complete CJTF, JFMCC, CTF One, and CTF Two Cycles (Data 
& Synchronization) 


Model Summary 

This model simulates a synchronous data scenario within 
a CJTF, JFMCC, CTF One, and CTF Two. Functions 
within the CJTF, JFMCC, CTF One, and CTF Two must 
wait for triggering data to be received before proceeding. 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP 2 CTF (with trig) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

11-Nov 

19:59 

16530.08 

21 

11-Nov 

20:37 

16537.14 

2 

11-Nov 

20:02 

16504.35 

22 

11-Nov 

20:39 

16478.96 

3 

11-Nov 

20:04 

16584.11 

23 

11-Nov 

20:41 

16519.59 

4 

11-Nov 

20:05 

16543.29 

24 

11-Nov 

20:43 

16567.28 

5 

11-Nov 

20:07 

16513.42 

25 

11-Nov 

20:45 

16501.04 

6 

11-Nov 

20:09 

16544.91 

26 

11-Nov 

20:47 

16508.96 

7 

11-Nov 

20:11 

16570.89 

27 

11-Nov 

20:49 

16582.98 

8 

11-Nov 

20:13 

16536.23 

28 

11-Nov 

20:50 

16561.55 

9 

11-Nov 

20:15 

16518.02 

29 

11-Nov 

20:52 

16521.45 

10 

11-Nov 

20:17 

16465.16 

30 

11-Nov 

20:54 

16482.21 

11 

11-Nov 

20:19 

16526.74 

31 

11-Nov 

20:56 

16542.41 

12 

11-Nov 

20:21 

16610.29 

32 

11-Nov 

20:58 

16634.68 

13 

11-Nov 

20:23 

16516.89 

33 

11-Nov 

21:00 

16525.16 

14 

11-Nov 

20:25 

16506.46 

34 

11-Nov 

21:02 

16559.82 

15 

11-Nov 

20:26 

16556 

35 

11-Nov 

21:04 

16496.89 

16 

11-Nov 

20:28 

16538.75 

36 

11-Nov 

21:06 

16574.57 

17 

11-Nov 

20:29 

16439.31 

37 

11-Nov 

21:08 

16500.24 

18 

11-Nov 

20:31 

16582.4 

38 

11-Nov 

21:09 

16553.09 

19 

11-Nov 

20:33 

16558.44 

39 

11-Nov 

21:11 

16519.08 

20 

11-Nov 

20:35 

16566.8 

40 

11-Nov 

21:13 

16582.07 
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Table 19 provides statisties calculated (using Microsoft Excel) from the sample data in 

run 8 


Table 19 - Run 8 Statistics 



Statistic 

Value 

1 

Minimum 

16439.31 

2 

Maximum 

16634.68 

3 

Range 

195.37 

4 

Average 

16536.54 

5 

Std Dev 

39.4275083 

6 

Conf90% 

10.2540774 

7 

conf 80% 

7.98923915 

8 

Variance 

1554.52841 
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I. Results for Run 9; CJTF, JFMCC, CTF One, CTF Two and CTF Three Functions 
Timing 

Table 20 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function executes as 
soon as it’s activated in the model. The total time to execute these functions form a baseline for 
comparison with simulation runs that will demonstrate synchronization of functions with data to 
demonstrate Command and Control cycle time. 

Table 20 - Time to Complete CJTF, JFMCC, CTF One, CTF Two, and CTF Three 
Functions 


Model Summary 

This model simulates a data only scenario (all function 
execute as soon as activated) with the CJTF, JFMCC, 

CTF One, CTF Two, and CTF Three 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP 3 CTF (data) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

15-Nov 

21:26 

7903.3 

21 

16-Nov 

15:40 

7887.51 

2 

15-Nov 

21:27 

7884.47 

22 

16-Nov 

15:42 

7876.52 

3 

15-Nov 

21:28 

7855.05 

23 

16-Nov 

15:43 

7870.85 

4 

15-Nov 

21:29 

7848.8 

24 

16-Nov 

15:45 

7850.35 

5 

15-Nov 

21:32 

7875.44 

25 

16-Nov 

15:47 

7866.42 

6 

15-Nov 

21:34 

7894.69 

26 

16-Nov 

15:49 

7884.37 

7 

15-Nov 

21:36 

7896.79 

27 

16-Nov 

15:51 

7887.64 

8 

15-Nov 

21:38 

7848.4 

28 

16-Nov 

15:53 

7849.46 

9 

15-Nov 

21:40 

7865.95 

29 

16-Nov 

15:54 

7841.09 

10 

15-Nov 

21:42 

7849.87 

30 

16-Nov 

15:56 

7853.89 

11 

15-Nov 

21:43 

7867.06 

31 

16-Nov 

15:57 

7843.16 

12 

15-Nov 

21:45 

7915.3 

32 

16-Nov 

15:59 

7887 

13 

15-Nov 

21:48 

7889.43 

33 

16-Nov 

16:01 

7890.83 

14 

15-Nov 

21:26 

7903.3 

34 

16-Nov 

16:03 

7887.61 

15 

15-Nov 

21:27 

7884.47 

35 

16-Nov 

16:05 

7835.87 

16 

15-Nov 

21:28 

7855.05 

36 

16-Nov 

16:06 

7850.74 

17 

15-Nov 

21:29 

7848.8 

37 

16-Nov 

16:08 

7867.61 

18 

15-Nov 

21:32 

7875.44 

38 

16-Nov 

16:11 

7885.49 

19 

15-Nov 

21:34 

7894.69 

39 

16-Nov 

16:12 

7861.47 

20 

15-Nov 

21:36 

7896.79 

40 

16-Nov 

16:14 

7868.84 
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Table TBS-21 provides statisties ealeulated (using Mierosoft Excel) from the sample data 
in run 9 


Table TBS-21 - Run 9 Statistics 



Statistic 

Value 

1 

Minimum 

7835.87 

2 

Maximum 

7915.30 

3 

Range 

79.43 

4 

Average 

7871.14 

5 

Std Dev 

18.9843311 

6 

Conf90% 

4.93733461 

7 

conf 80% 

3.84681579 

8 

Variance 

360.404828 
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J. Results for Run 10; CJTF, JFMCC, CTF One, CTF Two, and CTF Three 
(Synchronized with Data Triggers) 

Table 22 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 22 - Time to Complete CJTF, JFMCC, CTF One, CTF Two, and CTF Three 
Cycles (Data & Synchronization) 


Model Summary 

This model simulates a synchronous data scenario within 
a CJTF, JFMCC, CTF One, CTF Two, and CTF Three. 
Functions within the CJTF, JFMCC, CTF One, CTF Two, 
and CTF Three must wait for triggering data to be 
received before proceeding. 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP 3 CTF ( 

"with trig) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

11-Nov 

16:06 

16632.95 

21 

11-Nov 

16:56 

16618.68 

2 

11-Nov 

16:09 

16639.33 

22 

11-Nov 

16:58 

16576.28 

3 

11-Nov 

16:11 

16619.29 

23 

11-Nov 

17:00 

16624.1 

4 

11-Nov 

16:14 

16543.8 

24 

11-Nov 

17:03 

16679.91 

5 

11-Nov 

16:16 

16607.94 

25 

11-Nov 

17:06 

16626.43 

6 

11-Nov 

16:19 

16600.37 

26 

11-Nov 

17:08 

16590.75 

7 

11-Nov 

16:21 

16630.07 

27 

11-Nov 

17:10 

16629.21 

8 

11-Nov 

16:24 

16643.74 

28 

11-Nov 

17:12 

16554.8 

9 

11-Nov 

16:26 

16602.16 

29 

11-Nov 

17:15 

16631.45 

10 

11-Nov 

16:28 

16532.79 

30 

11-Nov 

17:17 

16623.78 

11 

11-Nov 

16:31 

16554.7 

31 

11-Nov 

17:19 

16642.74 

12 

11-Nov 

16:33 

16571.51 

32 

11-Nov 

17:21 

16613.45 

13 

11-Nov 

16:36 

16592.62 

33 

11-Nov 

17:23 

16639.67 

14 

11-Nov 

16:38 

16646.16 

34 

11-Nov 

17:26 

16566.05 

15 

11-Nov 

16:40 

16626.41 

35 

11-Nov 

17:29 

16592.72 

16 

11-Nov 

16:43 

16574.22 

36 

11-Nov 

17:31 

16599.62 

17 

11-Nov 

16:46 

16572.29 

37 

11-Nov 

17:33 

16650.19 

18 

11-Nov 

16:48 

16575.02 

38 

11-Nov 

17:35 

16573.83 

19 

11-Nov 

16:51 

16555.87 

39 

11-Nov 

17:37 

16626.15 

20 

11-Nov 

16:54 

16644.78 

40 

11-Nov 

17:40 

16599.37 
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Table 23 provides statisties calculated (using Microsoft Excel) from the sample data in 

run 9 


Table 23 - Run 10 Statistics 



Statistic 

Value 

1 

Minimum 

16532.79 

2 

Maximum 

16679.91 

3 

Range 

147.12 

4 

Average 

16605.63 

5 

Std Dev 

34.2844132 

6 

Conf90% 

8.91649113 

7 

conf 80% 

6.94708817 

8 

Variance 

1175.42099 
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K, Analysis of Data Variances 

In the data collected in paragraphs A, C, E, G and -I of this appendix, act as a control or 
basis for analysis of the various architecture options. Each of these runs represents time required 
to complete the Command and Control cycles unencumbered by any delays that may be created 
waiting for available data or responses. In our project’s case, each functions execution time was 
determined at random by the COREsim tool. To be sure that each sample of the control data is 
statically unique, an ANOVA test using Excel Data Analysis tools was used on the samples. 
Table TBS-23 contains the results of the ANOVA test 


Table 24 - Analysis of Variances 


SUMMARY 



Groups 

Count 

Sum 

Average 

Variance 

CJTF (no trigger) 

40 

312020 

7800.5 

372.1218 

CJTF +JFMC 

(no trigger) 

40 

311614.5 

7790.363 

606.2188 

CJTF +JFMC 

+ CTF One (no 





trigger) 

CJTF +JFMC 

+ CTF One + CTF Two 

40 

312020 

7800.5 

372.1218 

(no trigger) 
CJTF +JFMC 

+ CTF One + CTF Two 

40 

314636.2 

7865.905 

434.4144 

+ CTF Three 1 

[no trigger) 

40 

314845.7 

7871.143 

360.4048 

ANOVA 


Source of Variation 

SS 

df 

MS 

F P-value 

F crit 

Between Groups 

248012.6 

4 

62003.16 

144.5105 3.53E-57 

2.417963 

Within Groups 

83665.99 

195 

429.0563 



Total 

331678.6 

199 





Since the P-value is < 0.05, this is evidence that each of the data samples are statistically 
different (rejecting the null hypothesis that these samples have the same mean) 
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L, Results for Run 11; CJTF and JFMCC Functions Timing using the Clearinghouse 
Approach 

Table 25 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 25 - Time to Complete CJTF and JFMCC Functions using Clearinghouse 
Approach 


Model Summary 

This model simulates a data only scenario (all function 
execute as soon as activated) with the CJTF and JFMCC 
This approach simulates a data clearinghouse versus the 
stacked C2 wheels 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP Flat ( data and JFMCC) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

19-Nov 

20:06 

8069.11 

21 

19-Nov 

20:23 

8036.71 

2 

19-Nov 

20:08 

8067.4 

22 

19-Nov 

20:24 

8082.88 

3 

19-Nov 

20:09 

8076.24 

23 

19-Nov 

20:25 

8106.75 

4 

19-Nov 

20:10 

8059 

24 

19-Nov 

20:26 

8099.34 

5 

19-Nov 

20:10 

8091.61 

25 

19-Nov 

20:28 

8078.49 

6 

19-Nov 

20:11 

8077.16 

26 

19-Nov 

20:29 

8057.75 

7 

19-Nov 

20:12 

8076.57 

27 

19-Nov 

20:29 

8081.43 

8 

19-Nov 

20:13 

8089.68 

28 

19-Nov 

20:30 

8073.44 

9 

19-Nov 

20:13 

8087.76 

29 

19-Nov 

20:31 

8103.25 

10 

19-Nov 

20:14 

8092.07 

30 

19-Nov 

20:32 

8071.18 

11 

19-Nov 

20:15 

8101.21 

31 

19-Nov 

20:33 

8059.12 

12 

19-Nov 

20:15 

8097.53 

32 

19-Nov 

20:34 

8065.77 

13 

19-Nov 

20:16 

8106.32 

33 

19-Nov 

20:35 

8084.11 

14 

19-Nov 

20:17 

8063.82 

34 

19-Nov 

20:35 

8093.63 

15 

19-Nov 

20:18 

8076.61 

35 

19-Nov 

20:36 

8089.46 

16 

19-Nov 

20:19 

8068.84 

36 

19-Nov 

20:37 

8083.69 

17 

19-Nov 

20:20 

8092.03 

37 

19-Nov 

20:38 

8110.73 

18 

19-Nov 

20:20 

8076.73 

38 

19-Nov 

20:38 

8099.49 

19 

19-Nov 

20:21 

8054.83 

39 

19-Nov 

20:39 

8094.96 

20 

19-Nov 

20:22 

8098.25 

40 

19-Nov 

20:40 

8105.15 
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Table 26 provides statisties calculated (using Microsoft Excel) from the sample data in 

run 11 


Table 26 - Run 10 Statistics 



Statistic 

Value 

1 

Minimum 

8036.71 

2 

Maximum 

8110.73 

3 

Range 

74.02 

4 

Average 

8082.50 

5 

Std Dev 

16.9186692 

6 

Conf90% 

4.40010926 

7 

conf 80% 

3.42824846 

8 

Variance 

286.241368 


24 




APPENDIX D DATA ANALYSIS OF FUNCTIONAL MODEL 


M, Results for Run 12; CJTF and JFMCC (synchronized with Data Triggers) using the 
Clearinghouse Approach 

Table 27 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 27 - Time to Complete CJTF and JFMCC (Data & Synchronization) using the 
clearinghouse approach 


Model Summary 

This model simulates a synchronous data scenario 
within a CJTF and JFMCC. Functions within the CJTF 
and JFMCC must wait for triggering data to be received 
before proceeding. This approach simulates a data 
clearinghouse versus the stacked C2 wheels 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP Flat ( with trig CJTF & JFMCC) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

17-Nov 

15:11 

12436.12 

21 

17-Nov 

15:31 

12396.71 

2 

17-Nov 

15:13 

12380.85 

22 

17-Nov 

15:32 

12435.82 

3 

17-Nov 

15:13 

12406.1 

23 

17-Nov 

15:32 

12421.97 

4 

17-Nov 

15:15 

12394.71 

24 

17-Nov 

15:33 

12433.36 

5 

17-Nov 

15:16 

12401.23 

25 

17-Nov 

15:34 

12389.02 

6 

17-Nov 

15:17 

12468.81 

26 

17-Nov 

15:34 

12417.77 

7 

17-Nov 

15:18 

12370.69 

27 

17-Nov 

15:35 

12439.84 

8 

17-Nov 

15:19 

12438.97 

28 

17-Nov 

15:37 

12438.3 

9 

17-Nov 

15:20 

12434.56 

29 

17-Nov 

15:38 

12455.33 

10 

17-Nov 

15:21 

12428.25 

30 

17-Nov 

15:39 

12390.78 

11 

17-Nov 

15:22 

12394.97 

31 

17-Nov 

15:40 

12412.48 

12 

17-Nov 

15:23 

12417.21 

32 

17-Nov 

15:41 

12433.76 

13 

17-Nov 

15:23 

12407.67 

33 

17-Nov 

15:42 

12449.74 

14 

17-Nov 

15:24 

12403.58 

34 

17-Nov 

15:43 

12413.65 

15 

17-Nov 

15:25 

12447.84 

35 

17-Nov 

15:44 

12414.04 

16 

17-Nov 

15:26 

12380.1 

36 

17-Nov 

15:45 

12441.77 

17 

17-Nov 

15:27 

12458.40 

37 

17-Nov 

15:46 

12431.55 

18 

17-Nov 

15:28 

12417.71 

38 

17-Nov 

15:47 

12445.9 

19 

17-Nov 

15:28 

12389.65 

39 

17-Nov 

15:48 

12417.52 

20 

17-Nov 

15:30 

12446.96 

40 

17-Nov 

15:49 

12400.57 
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Table 28 provides statisties calculated (using Microsoft Excel) from the sample data in 


run 11 


Table 28 - Run 12 Statistics 



Statistic 

Value 

1 

Minimum 

12370.69 

2 

Maximum 

12468.81 

3 

Range 

98.12 

4 

Average 

12420.11 

5 

Std Dev 

24.0832781 

6 

Conf90% 

6.26343914 

7 

conf 80% 

4.880021 

8 

Variance 

580.004285 
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N. Results for Run 13; CJTF, JFMCC, and CTF One, Functions Timing using the 
Clearinghouse Approach 

Table 29 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 29 - Time to Complete CJTF, JFMCC, and CTF One Functions using 
Clearinghouse Approach 


Model Summary 

This model simulates a data only scenario (all function 
execute as soon as activated) with the CJTF, JFMCC, 
and CTF One. This approach simulates a data 
clearinghouse versus the stacked C2 wheels 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP Flat ( data and 2 CTF) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

19-Nov 

19:10 

8235 

21 

19-Nov 

19:32 

8158.91 

2 

19-Nov 

19:11 

8155.4 

22 

19-Nov 

19:33 

8221.78 

3 

19-Nov 

19:13 

8203.49 

23 

19-Nov 

19:34 

8208.18 

4 

19-Nov 

19:14 

8157.32 

24 

19-Nov 

19:35 

8205.38 

5 

19-Nov 

19:15 

8168.61 

25 

19-Nov 

19:36 

8194.63 

6 

19-Nov 

19:16 

8213.16 

26 

19-Nov 

19:37 

8222.33 

7 

19-Nov 

19:17 

8177.43 

27 

19-Nov 

19:38 

8189.96 

8 

19-Nov 

19:18 

8206.82 

28 

19-Nov 

19:40 

8170.97 

9 

19-Nov 

19:19 

8192.54 

29 

19-Nov 

19:41 

8197.56 

10 

19-Nov 

19:20 

8212.19 

30 

19-Nov 

19:42 

8229.32 

11 

19-Nov 

19:21 

8198.25 

31 

19-Nov 

19:43 

8208.07 

12 

19-Nov 

19:22 

8221.5 

32 

19-Nov 

19:44 

8210.56 

13 

19-Nov 

19:23 

8209.42 

33 

19-Nov 

19:45 

8194.28 

14 

19-Nov 

19:25 

8190.05 

34 

19-Nov 

19:46 

8186.8 

15 

19-Nov 

19:25 

8218.5 

35 

19-Nov 

19:47 

8201.68 

16 

19-Nov 

19:27 

8216.63 

36 

19-Nov 

19:48 

8216.84 

17 

19-Nov 

19:28 

8179.89 

37 

19-Nov 

19:50 

8215.58 

18 

19-Nov 

19:29 

8208.21 

38 

19-Nov 

19:51 

8220.61 

19 

19-Nov 

19:30 

8209.25 

39 

19-Nov 

19:52 

8209.59 

20 

19-Nov 

19:31 

8229.72 

40 

19-Nov 

19:53 

8217.84 
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Table 30 provides statisties calculated (using Microsoft Excel) from the sample data in 

run 11 


Table 30 - Run 13 Statistics 



Statistic 

Value 

1 

Minimum 

8155.40 

2 

Maximum 

8235.00 

3 

Range 

79.60 

4 

Average 

8202.11 

5 

Std Dev 

20.1562192 

6 

Conf 90% 

5.24211246 

7 

conf 80% 

4.08427675 

8 

Variance 

406.273173 
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O, Results for Run 14; CJTF, JFMCC, and CTF One (Synchronized with Data Triggers) 
using the Clearinghouse Approach 

Table 31 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 31 Time to Complete CJTF, JFMCC, and CTF One (Data & 
Synchronization) using the clearinghouse approach 


Model Summary 

This model simulates a synchronous data scenario 
within a CJTF, JFMCC, and CTF One. Functions 
within the CJTF, JFMCC, and CTF One must wait for 
triggering data to be received before proceeding. This 
approach simulates a data clearinghouse versus the 
stacked C2 wheels 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP Flat ( with trig and 2 CTF) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

17-Nov 

14:14 

15964.21 

21 

17-Nov 

14:42 

15912.63 

2 

17-Nov 

14:16 

15957.55 

22 

17-Nov 

14:44 

15903.4 

3 

17-Nov 

14:17 

16016.13 

23 

17-Nov 

14:45 

15930.34 

4 

17-Nov 

14:09 

16029.77 

24 

17-Nov 

14:47 

15947.02 

5 

17-Nov 

14:20 

15945.85 

25 

17-Nov 

14:48 

15898.02 

6 

17-Nov 

14:22 

15945.84 

26 

17-Nov 

14:50 

15985.6 

7 

17-Nov 

14:23 

15948.52 

27 

17-Nov 

14:51 

15907.73 

8 

17-Nov 

14:24 

15908.63 

28 

17-Nov 

14:52 

15944.34 

9 

17-Nov 

14:26 

15955.38 

29 

17-Nov 

14:54 

15942.09 

10 

17-Nov 

14:27 

15961.58 

30 

17-Nov 

14:55 

15994.07 

11 

17-Nov 

14:28 

15958.54 

31 

17-Nov 

14:56 

16013.56 

12 

17-Nov 

14:30 

15937.76 

32 

17-Nov 

14:57 

15928.86 

13 

17-Nov 

14:31 

15976.82 

33 

17-Nov 

14:59 

15951.82 

14 

17-Nov 

14:33 

15905.41 

34 

17-Nov 

15:01 

16012.25 

15 

17-Nov 

14:34 

15959.81 

35 

17-Nov 

15:02 

15946.58 

16 

17-Nov 

14:36 

15982.67 

36 

17-Nov 

15:04 

15986.6 

17 

17-Nov 

14:37 

15980.30 

37 

17-Nov 

15:05 

15946.41 

18 

17-Nov 

14:38 

15976.96 

38 

17-Nov 

16:06 

15967.39 

19 

17-Nov 

14:40 

15936.63 

39 

17-Nov 

15:08 

16016.32 
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20 

17-Nov 

14:41 

15867.35 

40 

17-Nov 

15:09 

15941.92 


Table 32 provides statisties ealculated (using Mierosoft Exeel) from the sample data in 

run 11 


Table 32 - Run 14 Statistics 



Statistie 

Value 

1 

Minimum 

15867.35 

2 

Maximum 

16029.77 

3 

Range 

162.42 

4 

Average 

15954.82 

5 

Std Dev 

36.1545329 

6 

Conf90% 

9.402861 

7 

conf 80% 

7.32603256 

8 

Varianee 

1307.15025 
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P. Results for Run 15; Results for Run 16; CJTF, JFMCC, CTF One, and CTF Two 
Functions Timing using the Clearinghouse Approach 

Table 33 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 33 - Time to Complete CJTF, JFMCC, CTF One and CTF Two Functions 
using Clearinghouse Approach 


Model Summary 

This model simulates a data only scenario (all function 
execute as soon as activated) with the CJTF, JFMCC, 

CTF One, and CTF Two This approach simulates a data 
clearinghouse versus the stacked C2 wheels 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP Flat (data and 3 CTF) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

19-Nov 

17:44 

8251.01 

21 

19-Nov 

18:13 

8272.3 

2 

19-Nov 

17:46 

8251.42 

22 

19-Nov 

18:15 

8297.73 

3 

19-Nov 

17:47 

8292.59 

23 

19-Nov 

18:16 

8279.29 

4 

19-Nov 

17:48 

8283.84 

24 

19-Nov 

18:17 

8269.39 

5 

19-Nov 

17:51 

8282.54 

25 

19-Nov 

18:18 

8288 

6 

19-Nov 

17:52 

8287.14 

26 

19-Nov 

18:20 

8275.8 

7 

19-Nov 

17:53 

8297.68 

27 

19-Nov 

18:21 

8298.65 

8 

19-Nov 

17:54 

8285.58 

28 

19-Nov 

18:23 

8270.11 

9 

19-Nov 

17:55 

8266.33 

29 

19-Nov 

18:24 

8289.05 

10 

19-Nov 

17:57 

8295.04 

30 

19-Nov 

18:25 

8262.22 

11 

19-Nov 

17:59 

8236.68 

31 

19-Nov 

18:26 

8271.27 

12 

19-Nov 

18:01 

8291.24 

32 

19-Nov 

18:29 

8280.66 

13 

19-Nov 

18:03 

8278.19 

33 

19-Nov 

18:30 

8251.29 

14 

19-Nov 

18:04 

8257.9 

34 

19-Nov 

18:31 

8291.73 

15 

19-Nov 

18:05 

8249.25 

35 

19-Nov 

18:32 

8265.87 

16 

19-Nov 

18:06 

8268.88 

36 

19-Nov 

18:33 

8272.8 

17 

19-Nov 

18:07 

8273.43 

37 

19-Nov 

18:35 

8284.24 

18 

19-Nov 

18:08 

8259.83 

38 

19-Nov 

18:37 

8294.75 

19 

19-Nov 

18:09 

8249.46 

39 

19-Nov 

18:38 

8289.8 

20 

19-Nov 

18:11 

8292.84 

40 

19-Nov 

18:39 

8273.38 
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Table 34 provides statisties calculated (using Microsoft Excel) from the sample data in 

run 13 


Table 34 - Run 15 Statistics 



Statistic 

Value 

1 

Minimum 

8236.68 

2 

Maximum 

8298.65 

3 

Range 

61.97 

4 

Average 

8275.73 

5 

Std Dev 

16.096058 

6 

Conf90% 

4.1861693 

7 

conf 80% 

3.26156184 

8 

Variance 

259.083082 
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Q. Results for Run 16; CJTF, JFMCC, CTF One, and CTF Two (Synchronized with Data 
Triggers) using the Clearinghouse Approach 

Table 35 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 35 - Time to Complete CJTF, JFMCC, CTF One, and CTF Two (Data & 
Synchronization) using the clearinghouse approach 


Model Summary 

This model simulates a synchronous data scenario within 
a CJTF, JFMCC, CTF One, and CTF Two. Functions 
within the CJTF, JFMCC, CTF One, and CTF Two must 
wait for triggering data to be received before proceeding. 
This approach simulates a data clearinghouse versus the 
stacked C2 wheels 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP Flat ( data and 3 CTF) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

17-Nov 

6:42 

16170.07 

21 

17-Nov 

13:37 

16125.1 

2 

17-Nov 

6:45 

16105.81 

22 

17-Nov 

13:38 

16193.22 

3 

17-Nov 

6:49 

16161.82 

23 

17-Nov 

13:40 

16154.39 

4 

17-Nov 

6:52 

16153.13 

24 

17-Nov 

13:42 

16129.8 

5 

17-Nov 

6:54 

16143.12 

25 

17-Nov 

13:43 

16122.91 

6 

17-Nov 

6:56 

16241.51 

26 

17-Nov 

13:45 

16178.44 

7 

17-Nov 

7:08 

16198.7 

27 

17-Nov 

13:47 

16153.95 

8 

17-Nov 

7:10 

16166.2 

28 

17-Nov 

13:49 

16186.8 

9 

17-Nov 

7:12 

16126.19 

29 

17-Nov 

13:50 

16131.51 

10 

17-Nov 

7:14 

16179.31 

30 

17-Nov 

13:52 

16160.11 

11 

17-Nov 

7:17 

16148.62 

31 

17-Nov 

13:53 

16096.47 

12 

17-Nov 

7:18 

16150.4 

32 

17-Nov 

13:56 

16099.12 

13 

17-Nov 

7:23 

16172.95 

33 

17-Nov 

13:57 

16110.18 

14 

17-Nov 

7:25 

16152.37 

34 

17-Nov 

13:59 

16113.63 

15 

17-Nov 

7:26 

16116.37 

35 

17-Nov 

14:01 

16110.04 

16 

17-Nov 

7:28 

16178.38 

36 

17-Nov 

14:03 

16234.66 

17 

17-Nov 

7:30 

16126.55 

37 

17-Nov 

14:05 

16189.68 

18 

17-Nov 

7:33 

16211.51 

38 

17-Nov 

14:07 

16108.66 

19 

17-Nov 

7:35 

16091.51 

39 

17-Nov 

14:08 

16100.92 
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20 

17-Nov 

7:40 

16146.38 

40 

17-Nov 

14:10 

16165.3 


Table 36 provides statistics calculated (using Microsoft Excel) from the sample data in 

run 13 


Table 36 - Run 15 Statistics 



Statistic 

Value 

1 

Minimum 

16091.51 

2 

Maximum 

16241.51 

3 

Range 

150.00 

4 

Average 

16150.14 

5 

Std Dev 

37.3991787 

6 

Conf90% 

9.72656126 

7 

conf 80% 

7.57823651 

8 

Variance 

1398.69857 
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R. Results for Run 17; CJTF, JFMCC, CTF One, CTF Two, and CTF Three Functions 
Timing using the Clearinghouse Approach 

Table 37 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 37 - Time to Complete CJTF, JFMCC, CTF One, CTF Two, and CTF Three 
Functions using Clearinghouse Approach 


Model Summary 

This model simulates a data only scenario (all function 
execute as soon as activated) with the CJTF, JFMCC, CTF 
One, CTF Two, and CTF Three. This approach simulates a 
data clearinghouse versus the stacked C2 wheels 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP Flat ( with trig and 3 CTF) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

17-Nov 

20:55 

8329.5 

21 

17-Nov 

21:28 

8306.24 

2 

17-Nov 

20:56 

8314.67 

22 

17-Nov 

21:30 

8319.59 

3 

17-Nov 

20:58 

8314.3 

23 

17-Nov 

21:33 

8310.59 

4 

17-Nov 

21:00 

8349.7 

24 

17-Nov 

21:34 

8329.23 

5 

17-Nov 

21:01 

8326.43 

25 

17-Nov 

21:36 

8336.46 

6 

17-Nov 

21:03 

8307.79 

26 

17-Nov 

21:37 

8329.79 

7 

17-Nov 

21:04 

8335.31 

27 

17-Nov 

21:39 

8328.21 

8 

17-Nov 

21:06 

8317.86 

28 

17-Nov 

21:41 

8325.31 

9 

17-Nov 

21:08 

8285.30 

29 

17-Nov 

21:42 

8359.19 

10 

17-Nov 

21:10 

8320.41 

30 

17-Nov 

21:44 

8344.99 

11 

17-Nov 

21:11 

8322.77 

31 

17-Nov 

21:46 

8328.69 

12 

17-Nov 

21:14 

8334.54 

32 

17-Nov 

21:47 

8344.23 

13 

17-Nov 

21:15 

8341.43 

33 

17-Nov 

21:51 

8336.44 

14 

17-Nov 

21:16 

8340.38 

34 

17-Nov 

21:52 

8328.75 

15 

17-Nov 

21:19 

8326.5 

35 

17-Nov 

21:53 

8342.35 

16 

17-Nov 

21:20 

8351.24 

36 

17-Nov 

21:55 

8341.63 

17 

17-Nov 

21:21 

8353.46 

37 

17-Nov 

21:57 

8351.82 

18 

17-Nov 

21:23 

8314.64 

38 

17-Nov 

21:58 

8347.74 

19 

17-Nov 

21:25 

8334.69 

39 

17-Nov 

22:00 

8336.94 

20 

17-Nov 

21:27 

8338.74 

40 

17-Nov 

22:02 

8342.01 
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Table 38 provides statisties calculated (using Microsoft Excel) from the sample data in 


run 13 


Table 38 - Run 15 Statistics 



Statistic 

Value 

1 

Minimum 

8285.30 

2 

Maximum 

8359.19 

3 

Range 

73.89 

4 

Average 

8331.25 

5 

Std Dev 

15.1496167 

6 

Conf90% 

3.94002434 

7 

conf 80% 

3.0697834 

8 

Variance 

229.510885 
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S. Results for Run 18; CJTF, JFMCC, CTF One, CTF Two, and CTF Three 
(Synchronized with Data Triggers) using the Clearinghouse Approach 

Table 39 contains the results from simulations using COREsim to model 50 cycles of the 
Command and Control decision cycle as discussed in paragraph IV.F. Each function cannot 
execute until all data for the function is available. This models the total time, including 
synchronizing effects, within and between organization to complete the Command and Control 
cycles. 


Table 39 Time to Complete CJTF, JFMCC, CTF One, CTF Two, and CTF Three 
(Data & Synchronization) using the clearinghouse approach 


Model Summary 

This model simulates a synchronous data scenario within 
a CJTF, JFMCC, CTF One, CTF Two, and CTF Three. 
Functions within the CJTF, JFMCC, CTF One, CTF 

Two, and CTF Three must wait for triggering data to be 
received before proceeding. This approach simulates a 
data clearinghouse versus the stacked C2 wheels 

CORE Repository Name 

Capstone 

Core Project Name 

Trusted COP Flat ( with trig and 3 CTF) 

Run 

Date of 
Run 

Time of 
Run 

Result 

Run 

Date of 
Run 

Time of 
Run 

Result 

1 

11-Nov 

21:25 

16217.26 

21 

11-Nov 

22:05 

16223.19 

2 

11-Nov 

21:27 

16135.44 

22 

11-Nov 

22:07 

16133.58 

3 

11-Nov 

21:29 

16150.44 

23 

11-Nov 

22:09 

16192.13 

4 

11-Nov 

21:31 

16194.77 

24 

11-Nov 

22:11 

16204.71 

5 

11-Nov 

21:33 

16205.77 

25 

11-Nov 

22:13 

16229.65 

6 

11-Nov 

21:35 

16245.62 

26 

11-Nov 

22:15 

16136.13 

7 

11-Nov 

21:37 

16157.09 

27 

11-Nov 

22:17 

16150.38 

8 

11-Nov 

21:39 

16163.38 

28 

11-Nov 

22:19 

16220.29 

9 

11-Nov 

21:41 

16223.92 

29 

11-Nov 

22:21 

16177.11 

10 

11-Nov 

21:43 

16181.01 

30 

11-Nov 

22:23 

16216.74 

11 

11-Nov 

21:45 

16245.79 

31 

11-Nov 

22:25 

16223.02 

12 

11-Nov 

21:47 

16237.07 

32 

11-Nov 

22:27 

16221.46 

13 

11-Nov 

21:49 

16210.68 

33 

11-Nov 

22:29 

16170.65 

14 

11-Nov 

21:51 

16193.3 

34 

11-Nov 

22:31 

16158.37 

15 

11-Nov 

21:53 

16173.31 

35 

11-Nov 

22:33 

16187.61 

16 

11-Nov 

21:55 

16174.18 

36 

11-Nov 

22:35 

16189.37 

17 

11-Nov 

21:57 

16162.66 

37 

11-Nov 

22:37 

16101.49 

18 

11-Nov 

21:59 

16231.23 

38 

11-Nov 

10:39 

16139.46 
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19 

11-Nov 

22:01 

16202.02 

39 

11-Nov 

10:41 

16126.71 

20 

11-Nov 

22:03 

16215.95 

40 

11-Nov 

22:43 

16202.8 


Table 40 provides statistics calculated (using Microsoft Excel) from the sample data in 

run 13 


Table 40 - Run 15 Statistics 



Statistic 

Value 

1 

Minimum 

16101.49 

2 

Maximum 

16245.79 

3 

Range 

144.30 

4 

Average 

16188.14 

5 

Std Dev 

36.3257834 

6 

Conf90% 

9.44739882 

7 

conf 80% 

7.36073323 

8 

Variance 

1319.56254 
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T, Analysis of Data Variances (for Clearing House Approach) 

The data collected in paragraphs L, N, P, and R of this appendix, act as a control or basis 
for analysis of the various architecture options. Each of these runs represents time required to 
complete the Command and Control cycles (using the clearinghouse approach) unencumbered 
by any delays that may be created waiting for available data or responses. In our project’s case, 
each functions execution time was determined at random by the COREsim tool. To be sure that 
each sample of the control data is statically unique, an ANOVA test using Excel Data Analysis 
tools was used on the samples. Table TBS-23 contains the results of the ANOVA test 


Table 41 Analysis of Variances (for Clearinghouse Approach) 

Anova: Single Factor 


SUMMARY 


Groups 

Count 

Sum 

Average 

Variance 

CJTF (no Trig) 

40 

312020 

7800.5 

372.1218 

CJTF +JFMC (no trig) 

40 

323300.1 

8082.503 

286.2414 

CJTF + JFMC + CTF One (no trig) 

40 

328084.3 

8202.106 

406.2732 

CJTF + JFMC + CTF One + CTF Two (no trig) 

40 

331029.2 

8275.73 

259.0831 

CJTF + JFMC + CTF One + CTF Two + CTF Three (no trig) 

40 

333249.9 

8331.247 

229.5109 


ANOVA 

Source of Variation 

SS 

df 

MS F 

P-value 

F crit 

Between Groups 

7096356 

4 

1774089 5710.966 

8.5E-201 

2.417963 

Within Groups 

60575.98 

195 

310.6461 




Total 


7156932 199 


Since the P-value is < 0.05, this is evidence that each of the data samples is statistically 
different (rejecting the null hypothesis that these samples have the same mean) 
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APPENDIX E OPERATIONAL EVENT TRACE DESCRIPTION 

(OV-6C) 


A, NAVY SATELLITE COMMUNICATIONS EXAMPLE (ASHORE - TO - 
AFLOAT) 


CJTF MOC 



NOC NCTAMS CTFOne 


JFMCC & 

CTF One & CTF Two 


Onto To CTF One & Two 


Data To CTF One & CTF 
Two 


Data To CTF One 


^ Data To CTF Two 


B. NAVY SATELLITE COMMUNICATIONS EXAMPLE (AFLOAT - TO - 
AFLOAT) 


CJTF MOC 


NOC 


K 

NCTAMS 



CTFOne CTFOne 


Data To CTF One 


Data To CTF One 


Data To CTF One 


Data To CTF One 


1 























C. C2 CYCLE ACTIVATION 








COCOM 

CJTF 

MOC 

CTFOne 

CTFTwo 

CTF Three 


Activate CJTF 

Stand Up C2 Watch at 








JFMCC 



Stand Up C2 Watch at 
CTFOne 

; Stand Up C2 Watch at 

J rXFTwo 





Stand Up C2 Watch at i 




CTF Three ; 






D, MAINTAIN ALIGNMENT 








COCOM 

CJTF 

MOC 

CTFOne 

CTFTwo 

CTFThree 


Commander's Intent. 
Mission Statement. 
Re-Prioritize Objectives 


Updates Objectives 
Updated Plan 


^ Commander's Intent. 

: Mission Statement. 

; Re-Prioritize Objectives 


Updates Objectives 
Updated Plan 


1 Commander’s Intent. 

: Mission Statement. 

; Re-Prioritize Objectives 

Commander's Intent. 
Mission Statement. 
Re-Priorltize Objectives 

Commander's Intent. 
Mission Statement. 
Re-Prioritize Objectives 







1*-' 


Updates Objectives 
Updated Plan 

!• 

Updates Objectives 
Updated Plan 

: Updates Objectives 
: Updated Plan 


2 
















E, 


PROVIDE SITUATIONAL AWARENESS 


COCOM 



MOC 



CTFOne CTFTwo CTFThree 


ISR Data, Top COP 
Feed. Special 
Instructions. SOPs 


Tactical ISR. CTP 
Updates to COP 


ISR Data. Top COP 

Feed. Special 

Instructions. SOPs 

ISR Data. Top COP 

Feed. Special 

Instructions. SOPs 

ISR Data, Top COP 

Feed. Special 

Instructions, SOPs 

ISR Data. Top COP 

Feed. Special 

Instructions, SOPs 










TacticallSR. CTP 

Updates to COP 


Tactical ISR, CTP 

Updates to COP 

VacticallSR, CTP 

Updates to COP 

Tactical ISR. CTP 

Updates to COP 



F, ADVANCE THE PLAN 








COCOM 

CJTF 

MOC 

CTFOne 

CTFTwo 

CTFThree 


Updated Plan 





Updated Plan 




Updated Plan 

Updated Plan 



* 

Updated Plan 











Plan Deviation 


!• 

Plan Deviation 



1 Plan Deviation 



Plan Deviation 



Plan Deviation 
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G 


COMPLY WITH PROCEDURE 








COCOM 

CJTF 

MOC 

CTFOne 

CTFTwo 

CTF Three 


Commander’s Intent, 
Commander's Guidance. 
Updated Plan 


Commander's Intent, 
Commander's Guidance. 
Updated Plan 


Commander's Intent, 
Commander's Guidance. 
Updated Plan 


Commander’s Intent, 
Commander's Guidance. 
Updated Plan 


Commander's Intent. 
Commander's Guidance. 
Updated Plan 


H, COUNTER THE ENEMY 




COCOM 


CJTF 






MOC 

CTFOne 

CTFTwo 

CTFThree 


Updated Plan. 
Guidance for Plan 
Changes 


Updated Plan. 
Guidance for Plan 
Changes 


Updated Plan. 
Guidance for Plan 
Changes 


Updated Plan. 
Guidance for Plan 
Changes 


Updated Plan, 
Guidance for Plan 
Changes 


4 















VI s 


I 


ADJUST APPORTIONMENT 




CJTF 


MOC 



CTFOne 



CTFTwo CTF Three 




_i- Request Changes to 

Request Changes to | Apportionment 

Apportionment I 


Request Changes to 
Apportionment 


I Request Changes to 
r Apportionment 
Request Changes to : 

Apportionment ; 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


A, OV-5a - Operational Activity Decomposition Tree 


hier Perform FBM Functions 



Project: 

Organization; 

Date: 

C2 Trusted COP 3 CTF 


November 25 , 2010 


Figure F-1. 0 - Perform FBM Functions 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


hier Perform Operations/Tactical Planning 




Project: 

C2 Trusted COP 3 CTF 

Organization: 

Date: 

November 25, 2010 




Figure F-2. 1 - Perform Operations Taetieal Planning 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


hier Provide APR Qverwatch J 




Project; 

C2 Trusted COP 3 CTF 

Organization: 

Date; 

November 25j 2010 




Figure F-3. 2 - Provide AOR Overwateh 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-4. 3 - Perforin CJTF Art of the C2 




hier Stand Up C2 Watch (at CJTF) ^ 



3.1 


Stand Up C2 
Watch (at CJTF) 


Function 


Project; 

Organiz... 

Date; 

C2 Trus... 


Novem... 


Figure F-5. 3.1 - Stand Up C2 Wateh (at CJTF) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-6. 3.2 - Maintain Alignment (at CJTF) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-7. 3.3 - Provide Situational Awareness (at CJTF) 


(at CJTF) J~ 


hier Advance the Plan 



Project; 


C2 Trusted COP 3 CTF 


Organization: 


Date; 


November 25j 2010 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-8. 3.4 - Advance the Plan (at CJTF) 



Figure F-9. 3.5 - Comply with Procedure (at CJTF) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-10. 3.6 - Counter the Enemy (at CJTF) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-11. 3.7 - Adjust Apportment (at CJTF) 



Figure F-12. 4 - Perform MOC art of C2 




hier Stand Up C2 Watch (at JFMCC)^ 



4.1 


Stand Up C2 
Watch (at JFMCC) 


Function 


Project; 

Organiz... 

Date; 

C2 Trus... 


Novem... 


Figure F-13. 4.1 - Stand Up C2 Wateh (at JFMCC) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-14. 4.2 - Maintain Alignment (at JFMCC) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-15. 4.3 - Provide Situational Awareness (at JFMCC) 


hier Advance the Plan (at JFMCC) J 



Project; 


C2 Trusted COP 3 CTF 


Organization: 


Date; 


November 25j 2010 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-16. 4.4 - Advance the Plan (at JFMCC) 



Figure F-17. 4.5 - Comply with Procedure (at JFMCC) 


12 



































APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-18. 4.6 - Counter the Enemy (at JFMCC) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-19. 4.7 - Adjust Apportment (at JFMCC) 



Figure F-20. 5 - Perform CTF One Art of C2 



Figure F-21. 5.1 - Stand Up C2 Watch (at CTF One) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-22. 5.2 - Maintain Alignment (at CTF One) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-23. 5.3 - Provide Situational Awareness (at CTF One) 


hier Advance the Plan (at CTF One) J 



Project; 


C2 Trusted COP 3 CTF 


Organization: 


Date; 


November 25j 2010 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-24. 5.4 - Advance the Plan (at CTF One) 



Figure F-25. 5.5 - Comply with Procudure (at CTF One) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-26. 5.6 - Counter the Enemy (at CTF One) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-27. 5.7 - Adjust Apportment (at CTF One) 



Figure F-28. 6 - Perform CTF Two Art of C2 



Figure F-29. 6.1 - Stand Up C2 Wateh (at CTF Two) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-30. 6.2 - Maintain Alignment (at CTF Two) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-31. 6.3 - Provide Situational Awareness (at CTF Two) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-32. 6.4 - Advance the Plan (at CTF Two) 



Figure F-33. 6.5 - Comply with Procedure (at CTF Two) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-34. 6.6 - Counter the Enemy (at CTF Two) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-35. 6.7 - Adjust Apportment (at CTF Two) 



Figure F-36. 7 - Perform CTF Three Art of C2 




hier Stand Up C2 Watch (at CTF.. 



7.1 


Stand Up C2 
Watch (at CTF ... 


Function 


Project; 

Organiz... 

Date; 

C2 Trus... 


Novem... 


Figure F-37. 7.1 - Stand Up C2 Wateh (at CTF Three) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-38. 7.2 - Maintain Alignment (at CTF Three) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-39. 7.3 - Provide Situational Awareness (at CTF Three) 


hier Advance the Plan (at CTF Three) J 



Project; 


C2 Trusted COP 3 CTF 


Organization: 


Date; 


November 25j 2010 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-40. 7.4 - Advance the Plan (at CTF Three) 



Figure F-41. 7.5 - Comply with Procedure (at CTF Three) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-42. 7.6 - Counter the Enemy (at CTF Three) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-43. 7.7 - Adjust Apportment (at CTF Three) 


B, OV-5b - Operational Activity Model (Functional Flow Block Diagram) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Ffbd Perform FBM Functions J 



Project; 

Organization; 

Date; 

C2 Trusted COP 3 CTF 


November 25j 2010 


Figure F-44. 0 - Perform FBM Funetions 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


ffbd Perform Operations/Tactical Planning 




Project; 

C2 Trusted COP 3 CTF 

Organization; 

Date; 

November 25, 2010 




Figure F-45. 1 - Perform Operations Tactical Planning 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-46. 1.1 - Perforin CTJF Planning 



Figure F-47. 1.2 - Perform Operations Taetical Planning 



Figure F-48. 1.3 - Perform CTF One Planning 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Ffbd Provide APR Overwatch J 




Project; 

C2 Trusted COP 3 CTF 

Organization; 

Date; 

November 25j 2010 




Figure F-49. 2 - Provide AOR Overwateh 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Pfbd Monitor Enemy J 



Project; 

Organization; 

Date; 

C2 Trusted COP 3 CTF 


November 25j 2010 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 

Figure F-49. 2.1 - Monitor Enemy 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


ffbd Anticipate Enemy Intent 




Project; 

C2 Trusted COP 3 CTF 

Organization: 

Date; 

November 25j 2010 




Figure F-50. 2.2 - Anticipate Enemy Intent 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-51. 3 - Perforin CJTF Art of the C2 



Figure F-52. 3.2 - Maintain Alignment (at CJTF) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-53. 3.3 - Provide Situational Awareness (at CJTF) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


ffbd Advance the Plan (at CJTF) J 




Project; 

Trusted COP 3 CTF (with trig) 

Organization: 

Date; 

November 29, 2010 




Figure F-54. 3.4 - Advance the Plan (at CJTF) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


ffbd Comply with Procedure (at CJTF) 



3,5.1 


Oversee 

Compliance (at... 

w 


COCOM JADOCS 


3.5,2 


Avoid Blue on 
Blue (at CJTF) 


COCOM ADSI 



3.5.3 


Achieve Plan 
Efficiency (at C... 

w 




Project; 

Organization: 

Date; 

Trusted COP 3... 


November 29,... 




Figure F-55. 3.5 - Comply with Procedure (at CJTF) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-56. 3.6 - Counter the Enemy (at CJTF) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Pfbd Adjust Apportment (at CJTF) J 




Project; 

Trusted COP 3 CTF (with trig) 

Organization: 

Date; 

November 29, 2010 




Figure F-57. 3.7 - Adjust Apportment (at CJTF) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


Figure F-58. 4 - Perform MOC art of C2 



Figure F-59. 4.2 - Maintain Alignment (at JFMCC) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


ffbd Provide Situational Awareness (at JFMCC) 




Project; 

Organization: 

Date; 

Trusted COPS... 


November 29,... 


Figure F-60. 4.3 - Provide Situational Awareness (at JFMCC) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


ffbd Advance the Plan (at JFMCC) J 



Project; 

Organization: 

Date; 

Trusted COP 3 CTF (with trig) 


November 29, 2010 


Figure F-61. 4.4 - Advance the Plan (at JFMCC) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-62. 4.5 - Comply with Procedure (at JFMCC) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 



Figure F-63. 4.6 - Counter the Enemy (at JFMCC) 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


ffbd Adjust Apportment (at JFMCC) 




Project; 

Organization: 

Date; 

Trusted COP 3 CTF (with trig) 


November 29, 2010 


Figure F-64. 4.7 - Adjust Apportment (at JFMCC) 

NOTE - Functions 5-7 have the same functional structure as Function 4. Functions 5-7 are related to CTF One, CTF Two, and CTF Three 
respectively. 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


C, Clearing House OV-5b 


ffbd Perform CJTF Art of thie C2 


DomainSet 001 


Stand Up C2 
Watch (at OT 


Stand Up C2 
Watch (at JFMi 


I'XV 


Provide AOR 
Overwatch 


Stand Up C2 
Watch (at CTF 




stand Up C2 
Watch (at CTF „ 


Stand Up C2 
Watch (at CTF „ 


■3.2 


Maintain 
Alignment (at 

:... , 




'4.2 


Maintain 
Alignment (at 






'5.2 


Maintain 
Alignment (at 





'6.2 


Maintain 
Alignment (at 

• 




'7.2 


Maintain 
Alignment (at 

• 




*3.3 

Provide 

Situational Awi 


Provide 

Situational Aw; 


Provide 

Situational Aw; 




Provide 

Situational Awi 


*7.3 


Provide 

Situational Awi 


*3.4 

Advance the P 
(at aTF) 


Advance the P 
(at 3FMCC) 


Advance the P 
(at CTF One; 




Advance the P 
at CTF Two 


*7.4 


Advance the P a 
(at CTF Three)- 


■3.5 


Comply with 
Procedure (at i™ 


Comply with 
Procedure (at ~ 


*3.6 

Counter the 
enemy (at 


Counter the 
enemy (at JFN... 


'5.5 

< 

Comply with 
Procedure at C 




"6.5 


Comply with 
Procedure at C 




7.5 


Comply with 
Procedure (at 




■3.7 


Adjust 
Apportment (ai: 


COCOM JADOCS 


Adjust 
Apportment (ai: 


Counter 

enemy 




■ 6.6 


Counter the 
enemy at CTF „ 


■7.6 


Counter the 
enemy (at CTF^ 




Adjust 
Apportment (af 


■7.7 


Adjust 
Apportment (af 



Trusted COP Flat (with trig and 3 CTF) 


November 21, 2010 


Figure F-65. Clearing House 3 - Perform CJTF Art of the C2 
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APPENDIX F OPERATIONAL ACTIVITY DECOMPOSITION TREE (OV-5A) 
AND OPERATIONAL ACTIVITY MODEL (OV5-B) 


D, COREsim Results 

One of the observations the project team made during development of the functional models was that each of the cycles tends to run at 
separate rates. Figure 25 shows a capture of CORE simulator. Each rectangle represents execution of a function. The top six rows represent the 
conclusion of functions belonging to the CJTF. The remainder of the functions belongs to the JFMCC. In this example the JMFCC cycles completed 
prior to the CJTF cycles. 



H la 

r Scale Conlrol- 


Tool' Help 
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■3 
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Edit Order 

\ Recompute Order ] 
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7100 
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7500 
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3 . 6.3 Continue The Plan (at CJTF) 

3.7.1 Monitor Availabihty and Attrition of F. 

3.7.2 Monitor Disposition and Attrition of., 

3.7.3 Monitor Changes to Enemy Tactics (,. 
3.7.4Monitor Changes in Priorities (atCJ... 
3.7.5 Adjust Resources at COCOM 

4.1 Stand Up C2 Watch (at JFMCC) 

4.2.1 Priororitize Mission Objectives (at... 

4.2.2 Identify Currently AvaialWe Resour., 

4.2.3 Determine Timeline for Inflowing Fo.. 

4.2.4 Determine Most Effective Resource ,. 
4.2. S Adjust Objectives (at JFMCC) 

4.3.1 Manage COP (at JFMCC) 

4.3.2 Incorporate Inteligence (at JFMCC) 

4.3.3 Monitor Networks (at JFMCC) 
4.3,4Monitor Comunications Circuits (at... 

4.4.1 Present Disposition of Friendly Fore... 

4.4.2 Present Enemy Forces Against Expe, 

4.4.3 Present Updated Mission Objectives . 
4.4,4Monitor Execution Against the Plan 

4.4.5 Adjust the Plan (at JFMCC) 

4.5.1 Oversee Compliance (at JFMCC) 

4.5.2 Avoid Blue on Blue (at JFMCC) 

4.5.3 Achieve Plan Efficiency (at JFMCC) 

4.6.1 Compare to Expected COAs (at JF... 

4.6.2 Make Plan Adjustment (at JFMCC) 


□ 


Figure F-66. COREsim Capture 
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APPENDIX G 


DYNAMIC MODELING 


AltOCurrent Architecture 
Command Task Force Elements 

Figure xx. below shows the basie network topology for the Combined Task Foree Operational 
Faeility (OPFAC). There are three (CTFl, CTF2, and CTF3) OPFACs in the baseline scenario. 
Table 1. Lists all the network devices and their corresponding function for the baseline scenario. 



Figure 1. CTF Network Topology 
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APPENDIX G 


DYNAMIC MODELING 


Device Name 

Function 

ctf3_client 

This device is an ethernet workstation 
which has the C2 client and heavy web 
browsing applications 

CTF3_server 

This device is an ethernet server that 

hosts both the C2 database and acts as a 

web server 

SATCOM_toJFMCC 

This is an SFIF SATCOM connection to the 

JFMCC 

SATCOM_to_CTFl 

This is an SFIF SATCOM connection to 

CTFl 

SATCOM_to_CTF2 

This is an SFIF SATCOM connection to 

CTF2 

CTF3_4500 

This is a Cisco 4500 series router acting as 
the ADNS router 


Table 1. CTF Device Descriptions 
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APPENDIX G 


DYNAMIC MODELING 


Satellite Operational Facilities 

In order to meet the requirements for the number of SATCOM circuits, the model 
employs three DSCS satellites. Three satellites were required as JCSS severely limits the 
number of SATCOM links. Figure 2 below shows the satellite Operational facility containing 
the three SATCOM li nk s. 


® ® ® 

satelliteDSCS_3 

atelliteDSCS satelliteDSCS_l 


Figure 2. Satellite Operational Facility 
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APPENDIX G 


DYNAMIC MODELING 


JFMCC OPFAC 

The JFMCC OPFAC contains the land-based SATCOM connections to the deployed 
CTFs. In addition, the MOC server is located in the JFMCC operational facility. This server 
synchronizes its COP picture with each of the deployed CTFs. 



Figure 3. JFMCC OPFAC 
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DYNAMIC MODELING 


Device Name 

Function 

SATCOM_to_CTF3 

This is an SFIF SATCOM connection to 

CTF3 

IVIOC_server 

This device is an ethernet server that 

hosts both the C2 database and acts as a 

web server 

SATCOM_toJFMCC 

This is an SFIF SATCOM connection to the 

JFMCC 

SATCOM_to_CTFl 

This is an SFIF SATCOM connection to 

CTFl 

SATCOM_to_CTF2 

This is an SFIF SATCOM connection to 

CTF2 

JFMCC_COMBAT_ROUTER 

This is a Cisco 7000 series router acting as 
the ADNS router 


Table 2. JFMCC Device Descriptions 
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DYNAMIC MODELING 


C JTF OPFAC 

The CJTF OPFAC has a fiber connection to the JFMCC. The 

CJTF_ASHORE_SERVER exchanges data with the JFMCC server. 



Figure 4. CJTF OPFAC 
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Source 

Destination 

Bandwidth 

(Kbps) 

Type 

Nw_Top.CTF2 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.JFMCC 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.CTF2 

2048 

satellite_tssp 

Nw_Top.CTF2 

Nw_Top.JFMCC 

1544 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.JFMCC 

1544 

satellite_tssp 

Nw_Top.JFMCC 

NwTop.CJTFAshore 

1000000 

lOOOBaseX 

Nw_Top.CTFl.ctfl_4500 

Nw_Top.CTFl.SATCOM_to_CTF2 

2048 

wire_ptp 

Nw_Top.CTFl.ctfl_4500 

Nw_Top.CTFl.SATCOM_to_CTF3 

2048 

wire_ptp 

Nw_Top.CTFl.SATCOM_toJFMCC 

Nw_Top.CTFl.ctfl_4500 

2048 

wire_ptp 

NwTop.CTFl.ctflclient 

Nw_Top.CTFl.ctfl_4500 

10000 

lOBaseT 

Nw_Top.CTFl.ctfl_4500 

NwTop.CTFl.ctflserver 

10000 

lOBaseT 

Nw_Top.CTF2.SATCOM_to_JFMCC 

Nw_Top.CTF2.ctf2_4500 

2048 

wire_ptp 

Nw_Top.CTF2.ctf2_client 

Nw_Top.CTF2.ctf2_4500 

10000 

lOBaseT 

Nw_Top.CTF2.ctf2_4500 

Nw_Top.CTF2.ctf2_server 

10000 

lOBaseT 

Nw_Top.CTF2.ctf2_4500 

Nw_Top.CTF2.SATCOM_to_CTFl 

2048 

wire_ptp 

Nw_Top.CTF2.ctf2_4500 

Nw_Top.CTF2.SATCOM_to_CTF3 

2048 

wire_ptp 

NwTop.JFMCC.MOCserver 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

10000 

lOBaseT 

Nw_Top.JFMCC.SATCOM_TO_CTF2 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

1544 

wire_ptp 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

Nw_Top.JFMCC.SATCOM_TO_CTF3 

1544 

wire_ptp 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

Nw_Top.JFMCC.SATCOM_TO_CTFl 

1544 

wire_ptp 

Nw_Top.CJTF_Ashore.CJTF_ASHORE_SERVER 

Nw_Top.CJTF_Ashore.CJTF_7505 

10000 

lOBaseT 

Nw_Top.CTF3.SATCOM_to_JFMCC 

Nw_Top.CTF3.ctf3_4500 

2048 

wire_ptp 

Nw_Top.CTF3.ctf3_4500 

Nw_Top.CTF3.SATCOM_to_CTFl 

2048 

wire_ptp 

Nw_Top.CTF3.ctf3_4500 

Nw_Top.CTF3.SATCOM_to_CTF2 

2048 

wire_ptp 

Nw_Top.CTF3.ctf3_client 

Nw_Top.CTF3.ctf3_4500 

10000 

lOBaseT 

Nw_Top.CTF3.ctf3_4500 

Nw_Top.CTF3.CTF3_server 

10000 

lOBaseT 


Table 3. Current Arehitecture Link Descriptions 
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DYNAMIC MODELING 


AltlUpgradedRouters 



Figure 5. CTF Network Topology with upgraded 7500 series routers. 
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DYNAMIC MODELING 


Alt2_Satellite_Capacity 


Source 

Destination 

Bandwidth (Kbps) 

Type 

Nw_Top.CTFl 

Nw_Top.CTF2 

2048 

satellite_tssp 

Nw_Top.CTF2 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.CTF2 

Nw_Top.JFMCC 

2048 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.JFMCC 

2048 

satellite_tssp 

Nw_Top.JFMCC 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.JFMCC 

Nw_Top.CJTF_Ashore 

1000000 

lOOOBaseX 

Nw_Top.CTFl.ctfl_client 

Nw_Top.CTFl.ctfl_4500 

10000 

lOBaseT 

Nw_Top.CTFl.SATCOM_toJFMCC 

Nw_Top.CTFl.ctfl_4500 

1544 

wire_ptp 

Nw_Top.CTFl.ctfl_4500 

N w_To p. CTF1. SATCO M_to_CTF3 

1544 

wire_ptp 

Nw_Top.CTFl.ctfl_4500 

Nw_Top.CTFl.SATCOM_to_CTF2 

1544 

wire_ptp 

Nw_Top.CTFl.ctfl_4500 

Nw_Top.CTFl.ctfl_server 

10000 

lOBaseT 

Nw_Top.CTF2.ctf2_client 

Nw_Top.CTF2.ctf2_4500 

10000 

lOBaseT 

Nw_Top.CTF2.SATCOM_toJFMCC 

Nw_Top.CTF2.ctf2_4500 

1544 

wire_ptp 

Nw_Top.CTF2.ctf2_4500 

Nw_Top.CTF2.SATCOM_to_CTF3 

1544 

wire_ptp 

Nw_Top.CTF2.ctf2_4500 

Nw_Top.CTF2.SATCOM_to_CTFl 

2048 

wire_ptp 

Nw_Top.CTF2.ctf2_4500 

Nw_Top.CTF2.ctf2_server 

10000 

lOBaseT 

Nw_Top.JFMCC.MOC_server 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

10000 

lOBaseT 

Nw_Top.JFMCC.SATCOM_TO_CTF2 

N w_To p. J FMCC.JFMCC_COM B AT_RO UTE R 

1544 

wire_ptp 

N w_To p. J FMCC.JFMCC_COM B AT_RO UTE R 

Nw_Top.JFMCC.SATCOM_TO_CTF3 

1544 

wire_ptp 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

Nw_Top.JFMCC.SATCOM_TO_CTFl 

1544 

wire_ptp 

Nw_Top.CJTF_Ashore.CJTF_ASHORE_SERVER 

Nw_Top.CJTF_Ashore.CJTF_7505 

10000 

lOBaseT 

Nw_Top.CTF3.ctf3_client 

Nw_Top.CTF3.ctf3_4500 

10000 

lOBaseT 

Nw_Top.CTF3.SATCOM_toJFMCC 

Nw_Top.CTF3.ctf3_4500 

1544 

wire_ptp 

Nw_Top.CTF3.ctf3_4500 

Nw_Top.CTF3.SATCOM_to_CTFl 

1544 

wire_ptp 

Nw_Top.CTF3.ctf3_4500 

Nw_Top.CTF3.SATCOM_to_CTF2 

2048 

wire_ptp 

Nw_Top.CTF3.ctf3_4500 

Nw_Top.CTF3.CTF3_server 

10000 

lOBaseT 


Table 4. Alternative 2 Link Report 
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DYNAMIC MODELING 


Alt_3_Router_Satellite_Upgrades 

A dedicated combat router was used to route C2 traffic in this scenario. Figure 6 below 
shows the new CTF network topology with dedicated combat router. 


SATCOM to JFMCC 




Figure 6. CTF OPFAC Alternative 3 
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DYNAMIC MODELING 


The JFMCC network topology was ehanged from the baseline seenario to aeeommodate the 
dedicated combat router. Figure? shows those changes. 




Figure 7. JFMCC OPFAC Alternative 3 




Bandwidth 


Source 

Destination 

(Kbps) 

Type 
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Nw_Top.CTF2 

Nw_Top.JFMCC 

2048 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.JFMCC 

2048 

satellite_tssp 

Nw_Top.JFMCC 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.CTF2 

Nw_Top.JFMCC 

2048 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.JFMCC 

2048 

satellite_tssp 

Nw_Top.JFMCC 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.CTF2 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.CTF2 

2048 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.JFMCC 

Nw_Top.CJTF_Ashore 

1000000 

lOOOBaseX 

Nw_Top.CTFl.ctfl_combat_client 

Nw_Top.CTFl.cisco4500 

10000 

lOBaseT 

N w_To p. CTF1. SATCO M_toJ F M CC 

Nw_Top.CTFl.cisco4500 

1544 

wire_ptp 

Nw_Top.CTFl.cisco4500 

N w_To p. CTF 1. SATCO M_to_CTF3 

1544 

wire_ptp 

Nw_Top.CTFl.cisco4500 

Nw_Top.CTFl.SATCOM_to_CTF2 

1544 

wire_ptp 

Nw_Top.CTFl.ctfl_ncJfmcc 

Nw_Top.CTFl.ctfl_nc_router 

1544 

wire_ptp 

Nw_Top.CTFl.ctfl_nc_client 

Nw_Top.CTFl.ctfl_nc_router 

10000 

lOBaseT 

Nw_Top.CTFl.cisco4500 

Nw_Top.CTFl.ctfl_combat_server 

10000 

lOBaseT 

Nw_Top.CTF2.ctf2_combat_client 

Nw_Top.CTF2.cisco4500 

10000 

lOBaseT 

Nw_Top.CTF2.SATCOM_toJFIVICC 

Nw_Top.CTF2.cisco4500 

1544 

wire_ptp 

Nw_Top.CTF2.cisco4500 

N w_To p. CTF2. SATCO M_to_CTF3 

1544 

wire_ptp 

Nw_Top.CTF2.cisco4500 

Nw_Top.CTF2.SATCOM_to_CTFl 

2048 

wire_ptp 

Nw_Top.CTF2.ctf2_ncJfmcc 

Nw_Top.CTF2.ctf2_nc_router 

1544 

wire_ptp 

Nw_Top.CTF2.ctf2_nc_router 

Nw_Top.CTF2.ctf2_nc_client 

10000 

lOBaseT 

Nw_Top.CTF2.cisco4500 

Nw_Top.CTF2.ctf2_combat_server 

10000 

lOBaseT 

Nw_Top.JFMCC.MOC_server 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

10000 

lOBaseT 

Nw_Top.JFMCC.SATCOIVI_TO_CTF2 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

1544 

wire_ptp 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

Nw_Top.JFMCC.SATCOM_TO_CTF3 

1544 

wire_ptp 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

Nw_Top.JFMCC.SATCOM_TO_CTFl 

1544 

wire_ptp 

Nw_Top.JFMCC.jfnncc_nc_rotuer 

Nw_Top.JFMCC.jfnncc_nc_server 

10000 

lOBaseT 

Nw_Top.JFMCC.satcom_nc_ctf2 

Nw_Top.JFMCC.jfmcc_nc_rotuer 

1544 

wire_ptp 

Nw_Top.JFMCC.jfnncc_nc_rotuer 

Nw_Top.JFMCC.satcom_nc_ctfl 

1544 

wire_ptp 

Nw_Top.JFMCC.jfnncc_nc_rotuer 

Nw_Top.JFMCC.satcom_nc_ctf3 

1544 

wire_ptp 

Nw_Top.CJTF_Ashore.CJTF_ASHORE_SERVER 

Nw_Top.CJTF_Ashore.CJTF_7505 

10000 

lOBaseT 

Nw_Top.CTF3.ctf3_combat_client 

Nw_Top.CTF3.cisco4500 

10000 

lOBaseT 

Nw_Top.CTF3.SATCOM_toJFMCC 

Nw_Top.CTF3.cisco4500 

1544 

wire_ptp 

Nw_Top.CTF3.cisco4500 

N w_To p. CTF3. SATCO M_to_CTF 1 

1544 

wire_ptp 

Nw_Top.CTF3.cisco4500 

Nw_Top.CTF3.SATCOM_to_CTF2 

2048 

wire_ptp 

Nw_Top.CTF3.ctf3_ncJfmcc 

Nw_Top.CTF3.ctf3_nc_router 

1544 

wire_ptp 

Nw_Top.CTF3.ctf3_nc_router 

Nw_Top.CTF3.ctf3_nc_client 

10000 

lOBaseT 

Nw_Top.CTF3.cisco4500 

Nw_Top.CTF3.ctf3_combat_server 

10000 

lOBaseT 


Table 5. Alternative 3 Link Report 

Alt_4_DiffServ and Alt_6_Priority_Queuing 
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APPENDIX G 


DYNAMIC MODELING 


The network topology for the Alternative was the same as that used in Alternative 0. However, 
DiflServ was used at the router interfaees. Traffie was marked differently for this seenario. 
Table XX below shows the applieation traffic and associated QoS. 


Node Name 

Profile Name 

QoS 

ctfl_client 

Database 

DiffServ 


Heavy_Web_200_user_LAN 

Best Effort 

ctf2_client 

Database 

DiffServ 


Heavy_Web_200_user_LAN 

Best Effort 

ctf3_client 

Database 

DiffServ 


Heavy_Web_200_user_LAN 

Best Effort 


Table 6. Alternative 4 and Alternative 6 Application Traffic Markings 
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Source 

Destination 

Bandwidth 

(Kbps) 

Type 

Nw_Top.CTFl 

Nw_Top.CTF2 

2048 

satellite_tssp 

Nw_Top.CTF2 

Nw_Top.CTF3 

2048 

satellite_tssp 

Nw_Top.JFMCC 

Nw_Top.CTF3 

1544 

satellite_tssp 

Nw_Top.CTF2 

Nw_Top.JFMCC 

1544 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.JFMCC 

1544 

satellite_tssp 

Nw_Top.JFMCC 

Nw_Top.CTF3 

1544 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.CTF3 

1544 

satellite_tssp 

Nw_Top.CTF2 

Nw_Top.JFMCC 

1544 

satellite_tssp 

Nw_Top.CTFl 

Nw_Top.JFMCC 

1544 

satellite_tssp 

Nw_Top.JFMCC 

Nw_Top.CJTF_Ashore 

1000000 

lOOOBaseX 

Nw_Top.CTFl.ctfl_combat_client 

Nw_Top.CTFl.cisco4500 

10000 

lOBaseT 

N w_To p. CTF1. SATCO M_toJ F M CC 

Nw_Top.CTFl.cisco4500 

1544 

wire_ptp 

Nw_Top.CTFl.cisco4500 

N w_To p. CTF 1. SATCO M_to_CTF3 

1544 

wire_ptp 

Nw_Top.CTFl.cisco4500 

Nw_Top.CTFl.SATCOM_to_CTF2 

1544 

wire_ptp 

Nw_Top.CTFl.ctfl_ncJfmcc 

Nw_Top.CTFl.ctfl_nc_router 

1544 

wire_ptp 

Nw_Top.CTFl.ctfl_nc_client 

Nw_Top.CTFl.ctfl_nc_router 

10000 

lOBaseT 

Nw_Top.CTFl.cisco4500 

Nw_Top.CTFl.ctfl_combat_server 

10000 

lOBaseT 

Nw_Top.CTF2.ctf2_combat_client 

Nw_Top.CTF2.cisco4500 

10000 

lOBaseT 

Nw_Top.CTF2.SATCOM_toJFMCC 

Nw_Top.CTF2.cisco4500 

1544 

wire_ptp 

Nw_Top.CTF2.cisco4500 

Nw_Top.CTF2.SATCOM_to_CTF3 

1544 

wire_ptp 

Nw_Top.CTF2.cisco4500 

Nw_Top.CTF2.SATCOM_to_CTFl 

2048 

wire_ptp 

Nw_Top.CTF2.ctf2_ncJfmcc 

Nw_Top.CTF2.ctf2_nc_router 

1544 

wire_ptp 

Nw_Top.CTF2.ctf2_nc_router 

Nw_Top.CTF2.ctf2_nc_client 

10000 

lOBaseT 

Nw_Top.CTF2.cisco4500 

Nw_Top.CTF2.ctf2_combat_server 

10000 

lOBaseT 

Nw_Top.JFMCC.MOC_server 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

10000 

lOBaseT 

Nw_Top.JFMCC.SATCOM_TO_CTF2 

Nw_Top.JFMCC.JFIV!CC_COMBAT_ROUTER 

1544 

wire_ptp 

N w_To p.JFMCC.JFMCC_COM B AT_RO UTE R 

Nw_Top.JFMCC.SATCOM_TO_CTF3 

1544 

wire_ptp 

Nw_Top.JFMCC.JFMCC_COMBAT_ROUTER 

Nw_Top.JFMCC.SATCOM_TO_CTFl 

1544 

wire_ptp 

Nw_Top.JFMCC.jfnncc_nc_rotuer 

Nw_Top.JFMCC.jfmcc_nc_server 

10000 

lOBaseT 

Nw_Top.JFMCC.satcom_nc_ctf2 

Nw_Top.JFMCC.jfmcc_nc_rotuer 

1544 

wire_ptp 

Nw_Top.JFMCC.jfnncc_nc_rotuer 

Nw_Top.JFMCC.satcom_nc_ctfl 

1544 

wire_ptp 

Nw_Top.JFMCC.jfnncc_nc_rotuer 

Nw_Top.JFMCC.satcom_nc_ctf3 

1544 

wire_ptp 

Nw_Top.CJTF_Ashore.CJTF_ASHORE_SERVER 

Nw_Top.CJTF_Ashore.CJTF_7505 

10000 

lOBaseT 

Nw_Top.CTF3.ctf3_combat_client 

Nw_Top.CTF3.cisco4500 

10000 

lOBaseT 

Nw_Top.CTF3.SATCOM_toJFMCC 

Nw_Top.CTF3.cisco4500 

1544 

wire_ptp 

Nw_Top.CTF3.cisco4500 

Nw_Top.CTF3.SATCOM_to_CTFl 

1544 

wire_ptp 

Nw_Top.CTF3.cisco4500 

Nw_Top.CTF3.SATCOM_to_CTF2 

2048 

wire_ptp 

Nw_Top.CTF3.ctf3_ncJfmcc 

Nw_Top.CTF3.ctf3_nc_router 

1544 

wire_ptp 

Nw_Top.CTF3.ctf3_nc_router 

Nw_Top.CTF3.ctf3_nc_client 

10000 

lOBaseT 

Nw_Top.CTF3.cisco4500 

Nw_Top.CTF3.ctf3_combat_server 

10000 

lOBaseT 
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DYNAMIC MODELING 


Table 7. Alternative 5 Link Descriptions 

Alternative 7 Clearing House 

This alternative has the same overall network topology as that used in the baseline scenario. 
However, database queries were made in a hub-spoke manner. Table 8 below shows the traffic 
source and destination demonstrating the common COP database. 


Source Node Name 

Profile Name 

Destination Node 

ctfl_client 

Database 

IVIOC_Server 


Heavy_Web_200_user_LAN 

ctf2_server, ctf3_server 

ctf2_client 

Database 

IVIOC_Server 


Heavy_Web_200_user_LAN 

ctfl_server, ctf3_server 

ctf3_client 

Database 

IVIOC_Server 


Heavy_Web_200_user_LAN 

ctfl_server, ctf2_server 


Table 8. Traffic source and destination nodes. 
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